So in my article on SPF, I briefly touched on how SPF only looks at a message’s envelope address, and not at the “From” address you see in the message headers, and that it’s not required for these addresses to match.

In my article on DKIM, I mentioned that DKIM alone only handles determining if a signature is valid, but isn’t concerned with the “From” address of the message. How to handle signatures, and whether or not they should match the “From” address is left up to local policy.

So you could have an email that passes SPF for one domain, has a valid DKIM signature from another domain, and use a third, totally unrelated domain as the “From” address. How do you determine if this email is actually legitimate or not?

Domain-based Message Authentication, Reporting, and Conformance (DMARC) is the solution.

Like a good rug, DMARC really ties the room together.

DMARC adds a new dimension to both SPF and DKIM - it essentially makes SPF and DKIM care about the “From” header. In order for a message to pass DMARC, it must:

  1. Pass SPF or have a valid DKIM signature, and:
  2. The passing SPF or DKIM result needs to be in alignment with the “From” address.

Domains can publish a DMARC policy that specifies:

  • Whether DKIM signatures should be in relaxed or strict alignment with the “From” domain.
  • Whether SPF results should be in relaxed or strict alignment with the “From” domain.
  • What to do with failing emails.

There’s more to DMARC, but the rest applies more to the domain owner, not you, the platform that just needs to send emails with somebody else’s domain.

You only need one passing result.

I’ve seen a lot of platforms require adding their “include” record to the client’s existing SPF record (which you shouldn’t do) as well as setting up DKIM keys - and refuse to start signing emails until they’ve validated both mechanisms. Since only one is necessary - it’s pretty silly to require clients to have both enabled.

Passing DMARC via SPF is stupid-easy with relaxed alignment.

If the client has a relaxed SPF alignment policy, it’s pretty easy to pass DMARC. Have the client create a subdomain with MX records pointing to your mail infrastructure, list your infrastructure in that subdomain’s SPF record, then use that subdomain in your envelope address.

If you want to make things even easier: make that subdomain a CNAME to something with the needed SPF and MX records. Now the client has a few less records to publish and maintain.

Honestly, though - you should mostly focus on DKIM.

Odds are your client isn’t using a lot of subdomains with your platform, so relaxed versus strict alignment doesn’t matter so much with DKIM. Unlike SPF, which limits how many DNS lookups can occur, clients can publish all the public keys they want for DKIM.

It’s probably best to just treat DKIM like all clients require strict alignment. Like I stated, they’re probably not using a ton of subdomains anyway (so there’s not that much overhead to maintaining subdomains separately); assuming strict alignment lets you pass relaxed alignment; and this should allow your messages to work with legacy systems that aren’t performing DMARC validation.

Since you just need one passing result - you can just skip SPF entirely. It’s less records for the client to maintain.

Thank you for reading!

Here’s links to other parts of the series.