Email authentication

Understanding SPF, DKIM, and DMARC are crucial to understanding mail that may be getting quarantined coming into your environment. It can also be important if you have a marketing team or other people bulk sending mail from the domain you manage.

The below is a high level summary to grasp the fundamentals, its more complicated than my basic examples show. A lot of websites exist to sell you a DMARC product and as such I think there's more obscurity out here than there needs to be and I will not point you to one source in particular.

SPF Record Explained

A typical SPF record for an Office 365 domain will look like this:

v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all

You can find detailed information about SPF records in many places. For now ensure you understand ip4 entries are IP addresses or ranges that are allowed to send emails for your domain. include entries state to look at the IP entries for the stated domain as additional IP addresses that can send email for your domain. The include is especially helpful if you use a bulk mailing service.

DKIM Records Explained

Typical DKIM records for an Office 365 domain will look like this:

selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft
selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

DKIM is used to sign elements of your email's header as well as the body of the email. So a private key stored in the sending mail service signs that content which can now be verified by looking up the emails DKIM selector and verifying it against the public key. Note that some services may only have one selector and you can have multiple DKIM records to cover multiple sending services.

Also note, if a user in your environment was compromised you may want to rotate your DKIM key because the contents of those signed emails created by an attacker can be reused to fool others that the email is legitimate from your domain.

DMARC Record Explained

A typical DMARC record might look like this:

v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

DMARC tells a receiving domain what to do with an email from your domain if it doesn't pass SPF or DKIM verification. The main element here is the p= entry, it can be set to none, quarantine, or reject and tells that receiving domain how you want that email treated.

Often misunderstood items

I will eventually cover more topics here but want to get a big one here for now, which is really around SPF alignment. There is also such a thing as DKIM alignment but SPF seems to be the often missed thing when evaluating quarantined email in Defender.

Let's imagine we want to send email for secoptimized.com via a bulk mailing service such as Amazon SES. Bulk mailers will often send mail from your domain, secoptimized.com in this case but the "return path" is actually from amazonses.com in our example. Mailing services do this to capture the potential return response NDR to know if perhaps a mailbox does not exist or other issues exist.

Field	Value
to	yourinbox@gmail.com
from	spam@secotpimized.com
return path	12345-abcde-67890-lmnop@amazonses.com
secoptimized.com SPF record	v=spf1 include:amazonses.com -all
secoptimized.com DKIM record	none
secoptimized.com DMARC record	v=DMARC1; p=reject;

Consider the above example, do you think this email will get delivered by Gmail?

Answer

As you may have guessed because this is the "misunderstood" item section, the answer is no this email is very unlikely to get delivered. To understand why we need to understand alignment which is very simple. If the from domain and the return path domain are not the same, SPF is not in alignment.

SPF checks are only performed on the return path domain. So in our example, the secoptimized.com SPF record is never checked. You might see "SPF Passed" in Defender because when we check the amazonses.com SPF record the message indeed came from Amazon's IP.

Alignment is a component of our DMARC record, it's great SPF passed, but it is misaligned, it passed for our bulk mailing service, not our domain.

If you are running into this challenge you need to bring SPF into alignment by ensuring your return path is your domain or more ideally, setup DKIM so Amazon is allowed to send on your behalf.

Below you can see a flowchart for how SPF, DKIM, and DMARC should be related. Note that while DMARC may specify to quarantine or reject, or perhaps "do nothing", it is the receiving domain's discretion as to how they handle the email. They are likely to be stricter in most cases (they are unlikely to care you have p=none if their users are reporting you for a ton of spam or phishing emails!).

flowchart TD
    A[Incoming Email] --> B{SPF Check}
    B -->|Pass| C{SPF Aligned?}
    B -->|Fail/None| F

    C -->|Yes| D[SPF+Alignment Pass]
    C -->|No| F{DKIM Check}

    F -->|Pass| G{DKIM Aligned?}
    F -->|Fail/None| J

    G -->|Yes| H[DKIM+Alignment Pass]
    G -->|No| J{DMARC Policy?}

    D --> K[DMARC Pass]
    H --> K

    J -->|p=none| L[Deliver Normally<br/>Send Reports]
    J -->|p=quarantine| M[Mark as Spam<br/>Send Reports]
    J -->|p=reject| N[Reject Email<br/>Send Reports]

    K --> O{DMARC Policy?}
    O -->|Any| P[Deliver Normally<br/>Send Reports]