When a Third-Party Tool Can't Email You

Here's a situation that comes up more than you'd think. You're in a quoting tool outside of JourneyFuse — Cruise Complete, a consortium booking engine, a supplier's agent portal — and you use its "email this quote" button to send a copy to yourself. Nothing arrives. No bounce in your sent folder, no error on screen, just silence. Or you get a rejection notice from your own mail provider.

Then you come to JourneyFuse to figure out what happened, because JourneyFuse is where that quote was headed.

JourneyFuse isn't in the path here. That email never touched us — it went from the third-party tool straight toward your mailbox and got stopped along the way. But it's worth understanding why, because the fix lives in DNS, and there's a way to skip email entirely and still get the quote into a trip in about thirty seconds.

Why It Happens

Most quoting tools don't send from their own address. They send as you — the From: line reads you@youragency.com or quotes@yourhostagency.com, so the quote looks like it came from your agency when you forward it to a client.

That's a nice touch, and it's also exactly what modern email security is built to stop. Every receiving mail server asks the same question: did the domain in the From: line actually authorize this server to send on its behalf? It answers by reading two DNS records on the sending domain:

Record	What it says
SPF	"These specific mail servers are allowed to send mail as my domain."
DKIM	"Real mail from my domain carries this cryptographic signature."

If the quoting tool's mail servers aren't listed in that domain's SPF record, and the tool doesn't sign with a DKIM key published on that domain, the message is unauthenticated. It is technically indistinguishable from someone forging your address.

That's exactly what happened in a real case: a host agency's SPF record authorized only Google Workspace and Mailgun. The quoting tool sent as that agency's domain from neither. Every receiving server that checked saw a message claiming to be from the agency, sent by a stranger.

Strict Forwarders Reject It Outright

Whether an unauthenticated message gets delivered, filed as spam, or refused entirely is up to the receiving side. Forwarding services are the strictest link in the chain, and Cloudflare Email Routing is the one that trips advisors up most often.

If you use an address on your own domain that forwards to your real Gmail or Outlook mailbox, that forwarder sits in the middle. It won't relay mail it can't authenticate — passing along a forged-looking message would put its own reputation behind it. So it refuses the message at the door, and it never lands anywhere.

Two things surprise people here:

• Your own domain's setup usually isn't the problem. In the case above, the advisor's personal domain was configured correctly — Cloudflare Email Routing with DMARC p=reject, exactly as recommended. It was the sending domain's missing authorization that caused the rejection.
• A lenient policy on the sending domain doesn't save you. An SPF record ending in ~all (softfail) and a DMARC p=none policy are a request that receivers go easy on unauthenticated mail. They aren't binding. A strict forwarder is free to refuse anyway, and Cloudflare does.

So you can have a permissive policy on one side, a correct setup on the other, and still get zero delivery.

How to Actually Fix It

The fix belongs on the domain in the From: line — usually your host agency's domain, not yours. That means it's typically a request to whoever administers that domain's DNS rather than something you can do yourself.

1. Find the vendor's sending instructions. Any tool that sends as a customer domain publishes what it needs — normally an SPF include: value, one or more DKIM CNAME records, or both. Look for "email authentication," "sender verification," or "email domain setup" in their docs or settings.
2. Add the SPF include. A domain gets exactly one SPF record, so the new value is added to the existing one — never published as a second record. Two SPF records on one domain is a configuration error and generally breaks authentication for everything.

   v=spf1 include:_spf.google.com include:mailgun.org include:vendor.example ~all
   

   Also watch the 10-lookup limit: SPF allows at most 10 DNS lookups, and each include: costs at least one. An agency stacking several vendors can quietly blow past it, which fails SPF for all senders at once.
3. Add the DKIM records. Usually CNAME records with vendor-supplied names. DKIM is the more durable of the two, because a DKIM signature survives forwarding while SPF does not.
4. Wait for DNS to propagate, then send yourself a test. Open the received message's raw headers and look for spf=pass or dkim=pass on the Authentication-Results line.

If the domain owner can't or won't make that change, there's still one thing you control: change the From: address inside the tool to an address on a domain that does authorize it, or to the vendor's own sending address if the tool offers that option.

The Faster Path: Skip Email Entirely

Honestly, for getting a quote into JourneyFuse, email was never the shortest route. You don't need it to arrive in your inbox at all.

Nearly every quoting tool has a Print or Download PDF option sitting right next to that email button. Save the quote to your computer, then hand the file to AI Booking Import — it reads the PDF and pulls out the supplier, ship or property, dates, cabin or room details, confirmation number, pricing, and traveler names, then builds the booking for you. A screenshot works too if the tool won't produce a PDF.

Two places to drop it in:

• On a trip — open the trip and click AI Import Booking in the header. The booking lands directly on that trip.
• In a proposal — open a draft proposal and click AI Import in the outline header. The button is disabled once a proposal has been sent or published, so move it back to draft first.

You can also start from the Import Booking button on your dashboard or the AI Import button on the Trips page if you don't have a trip yet — JourneyFuse will create one.

This bypasses the authentication chain completely, and it's fewer clicks than emailing yourself and forwarding the result anyway.

Quick Diagnosis

If you want to confirm this is what you're dealing with before you go asking for DNS changes:

• Look at the From: address the tool is using. If it's on a domain other than the vendor's own, the tool is sending as that domain and needs authorization from it.
• Check whether anything arrives at a plain mailbox. Send the same quote to a Gmail or Outlook address that isn't behind a forwarder. If it lands there but not at your forwarded address, the forwarder is doing the rejecting — which points squarely at authentication.
• Read the rejection notice, if you got one. Wording like "does not pass SPF," "unauthenticated," "550 5.7.x," or "not authorized to send" names the problem directly.
• Note whether your own address forwards. If it runs through Cloudflare Email Routing or a similar service, say so when you report the issue — it explains why the same quote might reach a colleague and not you.

What JourneyFuse Handles

For clarity on where the line sits: JourneyFuse manages authentication for the email we send on your behalf, and for the custom domain you've connected to us. See Sending Emails and Connecting Your Email for that side of things.

Mail sent by an outside tool, from its own servers, is between that tool and the DNS of the domain it's sending as. We can't authorize it and we never see it — but the PDF route above gets you to the same place without needing it to work at all.