Remove or change sp= in the DMARC policy

[philsward]

Helping @BWPanda with some email authentication stuff, I dug into the policies with backdropcms.org and found that the DMARC policy is telling email recipients to fully allow all email from backdropcms.org subdomains regardless of the SPF or DKIM setting. This allows for spoofing on backdropcms.org subdomains.

Record _dmarc.backdropcms.org text = "v=DMARC1\; p=quarantine\; pct=100\; rua=mailto:qryt3azx@ag.dmarcian.com,mailto:dmarc@mailinblue.com!10m\; ruf=mailto:dmarc@mailinblue.com!10m\; sp=none\; rf=afrf\; ri=86400"

Investiagation 1) Is this the intended policy?

2) Do the subdomains have their own DMARC policy in place to mitigate the parent one?

Note: In theory, a spoofer can send email from any subdomain, regardless of whether the CNAME actually exists.

Proposal Options 1) Remove sp=none

This means all subdomains now take on the same setting as the parent (p=)

2) Change sp=quarantine

This will force all subdomains to send the quarantine flag to the receiving mail server.

References https://dmarc.org/ https://tools.ietf.org/html/rfc7489 https://securityboulevard.com/2019/12/how-dmarc-works-with-subdomains-and-the-sp-tag/

Initial issue for b.org DMARC policy: https://github.com/backdrop-ops/backdropcms.org/issues/607

[jenlampton]

found that the DMARC policy is telling email recipients to fully allow all email from backdropcms.org subdomains regardless of the SPF or DKIM setting. This allows for spoofing on backdropcms.org subdomains.

We currently send email from many backdropcms.org subdomains, but we do not send emails from backdropcms.org without a subdomain. Would changing this setting jeopardize our emails?

Is this the intended policy?

The intent is for all email from *.backdropcms.org to end up in inboxes and not in spam folders. We have found it nearly impossible to manage this ourselves, so we have delegated all sending of email messages to SendGrid. (Which has solved the problem)

Do the subdomains have their own DMARC policy in place to mitigate the parent one?

No subdomains have a DMARC policy, as far as I can tell. The only DMARC record we have is a single text record for _dmarc.backdropcms.org.

Change sp=quarantine ... This will force all subdomains to send the quarantine flag to the receiving mail server.

Does this mean that email sent from all of our sites would be quarantined instead of delivered?

Remove sp=none ... This means all subdomains now take on the same setting as the parent (p=)

But right now, we have p=quarantine ... doesn't this mean that email sent from all of our sites would be quarantined instead of delivered?

[philsward]

We currently send email from many backdropcms.org subdomains, but we do not send emails from backdropcms.org without a subdomain. Would changing this setting jeopardize our emails?

Not if the DKIM and SPF are properly setup for those subdomains. The SPF is set at the domain level, the DKIM is usually setup for each specific domain (primary and sub). With DKIM, the one saving grace is that SMTP relay servers can sign their own DKIM authentication with the message, allowing it to pass. This is probably happening with SendGrid. The downside, is that the DKIM is not authenticating with YOUR domain, which can be seen as a bad actor from the recipient. For example If DKIM doesn't match the incoming email domain, even though it passes with another domain, reject the message anyway I don't know if any incoming servers are setup this way, but it's possible. The big ones probably aren't (google, hotmail etc) but small ISP's that don't have dedicated filtering might set their servers up this way.

No subdomains have a DMARC policy, as far as I can tell. The only DMARC record we have is a single text record for _dmarc.backdropcms.org.

This is fine because p= is a fallback for all subdomains 'if' sp= is missing.

Does this mean that email sent from all of our sites would be quarantined instead of delivered?

and

But right now, we have p=quarantine ... doesn't this mean that email sent from all of our sites would be quarantined instead of delivered?

The short answer: Not if the SPF and DKIM keys are properly setup.

The p= (primary domain) and sp= (subdomain) are there to tell the receiving server what to do with a message "if" SPF and DKIM and DMARC policies are either missing or failing. Quarantine says "If SPF and(or) DKIM and(or) DMARC are missing or fail, do this".

We are telling the receiving server "If an email comes in and the SPF fails, we recommend that you quarantine the message because we probably didn't send it. Same with DKIM.

Over time, using a service like https://dmarcian.com/ or https://www.dmarcanalyzer.com/ you can see which IP's are sending email on your behalf and which of those emails have SPF and DKIM pass or failure rates. If you feel like the ones that are all passing are being sent from legitimate sources, you can set p=reject which will tell the receiving server "If SPF and DKIM are bad, we recommend that you do NOT deliver it!"

so, p=none or sp=none is telling the server "Even if you suspect the message is spoofed because SPF and DKIM are failing, go ahead and try to deliver the message anyway".

This is bad, because we are letting spoofers send email on behalf of *.backdropcms.org and telling servers: "Let it through! Please!"

Clear as mud? ;-)

[jenlampton]

This is probably happening with SendGrid. The downside, is that the DKIM is not authenticating with YOUR domain

We added a ton of additional DNS records specifically for sendgrid to authenticate with our domain. Is it possible that authentication is happening in some way other than via DKIM records?

Quarantine says "If SPF and(or) DKIM and(or) DMARC are missing or fail, do this".

Aha!

so, p=none or sp=none is telling the server "Even if you suspect the message is spoofed because SPF and DKIM are failing, go ahead and try to deliver the message anyway".

So it's likely this was added one of the times our emails were being marked as spam and not getting through to people...

Not if the DKIM and SPF are properly setup for those subdomains.

Okay, what does this mean practically? What do I need to add to set up each subdomain properly? And, will we need to do this every time we set up a new one?

[philsward]

I'll address these after bit. In the meantime, who setup the dmarcian account? It should have some good info on past reports.

rua=mailto:qryt3azx@ag.dmarcian.com

Not sure what mailinblue.com is which is where additional reports are going.

rua = general reports ruf = forensic reports (usually have to pay for this on most services)

[jenlampton]

Not sure what mailinblue.com is which is where additional reports are going.

That's the tool we are using for our newsletter mailing list at the moment.

[philsward]

That's the tool we are using for our newsletter mailing list at the moment.

Ok. I find it odd they want DMARC reporting, but maybe they have some stuff on their end to help show deliverability which would make sense.

We added a ton of additional DNS records specifically for sendgrid to authenticate with our domain. Is it possible that authentication is happening in some way other than via DKIM records?

Ok. This is good and what I would expect. Every sending server must have it's own email key pair for each sending domain. I have a feeling that sendgrid is using some generic records that points back to them and allows you as the customer to create 100 different subdomains, but they are all covered under the initial settings. (So you don't have to add a new DKIM for every domain). Check with the respective service on this one. I've seen it go both ways.

So it's likely this was added one of the times our emails were being marked as spam and not getting through to people...

It is very possible. Let's say for example that you have the IP's for sendgrid in the SPF and DKIM setup for sendgrid on newsletter.backdropcms.org, but you never setup the IP's in the SPF and DKIM for blueinmail.com, the quarantine would tell the receiving server: "We recommend that you allow stuff from sendgrid, but you should probably block anything from blueinmail or anywhere else that says the mail is from us because it probably isn't".

So yes, if things aren't setup right and legit mail isn't getting delivered, setting the p or sp to none ensures that the mail has a higher chance of getting delivered, including bad mail from spoofers. From here, the message is dependent on the receiving server and how strict or relaxed they are.

Domain Settings none = I just set up the protocols and need some time to gather reports quarantine = The protocols are working, I have some reports, but I need some more time just to make sure I didn't forget or miss anything. reject = I'm good to go on my end! lock my S#!& down cuz middle finger to the spoofers!

Okay, what does this mean practically? What do I need to add to set up each subdomain properly? And, will we need to do this every time we set up a new one?

For the DMARC, I would set the p= to quarantine and sp= quarantine. This will cover the main domain and all subdomains, but gives some flexibility between the main and subs. From what you've described, emails "should" be authenticating and the SPF records should be good. Looking at Dmarcian for this information will help show if things are good or not. (You'll probably be amazed at how much spoofing is going on...)

From your standpoint of backdropcms.org, the only time you would really need to worry about doing anything different for each subdomain is if the sending server is different than what you're already using. If so, you would need to add the new service to the SPF and add the DKIM for the new service. This is where the question about whether Sendgrid is controlling ALL DKIM references or if you need to get a new one for each domain comes in.

Note: Incoming email servers check _dmarc.xyz.backdropcms.org first and if that doesn't exist, looks at _dmarc.backdropcms.org. If sp= is set, is uses that. If it isn't set (missing) then it defaults to whatever p= is.

Note: If there is no DMARC record for the primary domain (_dmarc.backdropcms.org) is the same as setting p= & sp= none. This is bad because you leave it up to the receiving server to do whatever the heck they want with mail.

[jenlampton]

For the DMARC, I would set the p= to quarantine and sp= quarantine.

Okay, I'll do this now. 🤞

[philsward]

Forgot to mention, the none, quarantine, reject is counterintuitive.

"When I set it to none, more mail gets through". Yes, but you have no control over what SHOULD get through. If a spoofer uses your domain, you risk getting your domain blacklisted by the receiving server because it can't be trusted.

Quarantine is the gray area because you are telling the server not to trust some of your email, but also telling it to make sure it CAN be trusted. This gives the incoming server reason to trust you if the domain or IP is blacklisted.

Reject gives you full control over the legitimacy of your emails. You are telling the incoming server "Don't trust ANY email, unless you get the secret handshake."

[philsward]

Okay, I'll do this now. 🤞

Sounds good. If you get some deliverability problems, it's because the SPF or DKIM isn't right.

See if you can get into dmarcian for insight into how email has been doing so far. It should show you email per subdomain so if there's one subdomain for example that is 100% out of alignment then you know it needs some serious attention.

[philsward]

The one specification I never brought up is BIMI. It's new, in alpha testing and has a cost associated with it. Long story short, it authenticates your domain with a CA store and attaches your logo to the record so your brand logo shows up in emails. It's nothing we need to worry about anytime soon which is why I didn't mention it.