Email Routing where sender has strict DMARC lands in spam

Sending email from a domain with a strict DMARC setting (and both DKIM and SPF configured; email hosted by iCloud) to a domain configured with Cloudflare Email Routing with the forwarding address as a Gmail account seems to result in the forwarded email landing in spam.

Sending from another Gmail account lands the forwarded mail in the Gmail inbox.

While I could relax the DMARC controls on my custom domain, I’m worried that some mail sent by others and forwarded through Cloudflare Email Routing is going to end up in spam if coming from domains with strict DMARC settings. Is there a recommended setup in Gmail and/or on the domain with Email Routing enabled to overcome Gmail’s treatment of these messages as spam?

1 Like

DMARC just means the mail failed either DKIM or SPF. Now the question is: which of those failed? The full headers of the flagged message should show you which failed. Have you checked those headers?

Gmail reports SPF passed, DMARC failed.

In the headers the only mention of DKIM is

Authentication-Results: mx.cloudflare.net; spf=pass; dkim=neutral; dmarc=pass;

I see Google’s Authentication-Results record as

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of <icloud email>@<domain> designates 104.30.5.56 as permitted sender) smtp.mailfrom="<icloud email>@<domain>";
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=<icloud email domain>

Sven can probably see where the problem is if you send him the complete un-edited headers. He’s on the Cloudflare Developers discord server in his link.

1 Like

For me also emails from GMail to email routed email address on GMail also ends up in spam.
And from my work email I see in the headers:
Authentication-Results: mx.cloudflare.net; spf=pass; dkim=neutral; dmarc=none;
And it also end up in spam.

Any news in this topic?

Does the mail headers give any indicator of why DKIM failed ? What You Need To Know About DKIM Fail

Why do I see DKIM= neutral (body hash did not verify)?

When the body hash verification fails, that means the computed hash of the message body does not agree with the body hash value stored in the “bh=” tag of the DKIM signature.

Some corporate email servers append inline text to the bottom of incoming emails before anti-spam agents parse them. In situations like that, the body hash would be invalidated.

The email(s) from this source failed the DMARC check. This means that the email was not DMARC compliant, therefore SPF and DKIM are both invalid. This can mean two things:

The source failed the DMARC checks because DKIM and/or SPF were not set up correctly;

The source failed the DMARC checks because someone has sent malicious emails on behalf of your domain.

and

Several reasons that may cause DKIM= neutral (body hash did not verify)

  • A forwarder, a smart-host, or another filtering agent modified the body of the email;
  • The signer calculated the signature value incorrectly;
  • Someone spoofed the email and signed it without having the correct private key.
  • The public key specified in the DKIM-Signature header is wrong;
  • The public key published by the sender in their DNS is wrong;

The steps that you can take to investigate the source:

  • Do I recognize the source as a partner of my company?
  • Search on Google what kind of source this is.
  • Does the source appear on RBL blacklist websites?
  • Check the forensic reports to see what kind of emails the source sends.
  • If the source is valid, search for documentation to set up DMARC correctly.
  • Contact the source.
1 Like

I have checked another emails, also lended automatically in spam, no problems with DMARC nor DKIM, there:

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1 header.b=nBzpYBp+;
arc=pass (i=1);
spf=pass (google.com: domain of [email protected] designates 104.30.5.21 as permitted sender) smtp.mailfrom="[email protected]";
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=netapp.com

Why this still ends up in spam ?

I’m seeing DMARC fail due to ARC auth problems.

Before Cloudflare email

ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass [email protected] header.s=default header.b=TikN9w5D;
       arc=pass (i=1 spf=pass spfdomain=redfin.com dkim=pass dkdomain=redfin.com dmarc=pass fromdomain=redfin.com);

after

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=2022 header.b=TaCH+H3G;
       dkim=neutral (body hash did not verify) [email protected] header.s=default header.b=qnpVt9EQ;

This leads to DMARC failing

Here is another case of Gmail marking a third-party email as spam. SPF, DKIM: pass, DMARC: fail. I can provide the full headers if needed.

ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=2022 header.b=bXLeAtDa;
       spf=pass (google.com: domain of [email protected] designates 104.30.4.58 as permitted sender) smtp.mailfrom="[email protected]";
       dmarc=fail (p=REJECT sp=REJECT dis=QUARANTINE) header.from=euromsg.net

Would it be possible to implement it as more “pass-through”? I guess Gmail uses Cloudflare rather than the sender for checking DMARC.

This is all a bit technical for me, but since I signed up for using Cloudflare email routing I’m getting these kinds of error reports, and don’t know what I can do about them? (Except perhaps not use Cloudflare?)

I’m not an expert here, but I believe what’s going on is that the smtp.mailfrom (also known as RFC5321.MailFrom) header and the RFC5322.From header are “unaligned” (they have different domains).

Using the example above:

Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=selector1 header.b=nBzpYBp+;
arc=pass (i=1);
spf=pass (google.com: domain of [email protected] designates 104.30.5.21 as permitted sender) smtp.mailfrom="[email protected]";
dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=netapp.com

RFC5321.MailFrom = domainOf([email protected]) = matrix.pl.eu.org
RFC5322.From = domainOf([email protected]) = netapp.com

Since the domains are different, the headers are “unaligned” and dmarc fails.

Why is the RFC5321.MailFrom changed? For SPF checks. SPF will lookup the domain based on the RFC5321.MailFrom, and since the sending IP is now from Cloudflare (due to forwarding) the RFC5321.MailFrom is changed to a DNS record controlled by your domain in Cloudflare.

Now, the question is - what to do about the send to spam? Again I’m no expert (far from it).

Options:

  1. Cloudflare should not modify the RFC5321.MailFrom header and just allow SPF to fail.
  2. I’ve seen other forwarding platforms add X-Forwarded-To and X-Forwarded-For headers. Maybe that helps to identify forwarded mail?
1 Like

I encountered this as well, but I think there is an easy fix would ask others to confirm.

  1. Configure CF email forwarding catch-all to target address.
  2. Send to catch-all from an account other than the target.
  3. Mark the received email as “not spam”.

This not only made all subsequent emails to the catch-all appear properly in the target inbox, it fixed all other CF catch-alls (at least for me). So just by correcting one spam from one CF catch-all fixed them all.

Please confirm. Otherwise a test email from every CF catch-all must be marked as not spam (still not a bad solution - at least it will work for sure, but may not be necessary).