This chapter covers SPF, DKIM, and DMARC — the three pillars of email authentication in Microsoft 365. These technologies are critical for preventing spoofing and phishing attacks that impersonate your domain. On the MS-102 exam, this topic appears in roughly 10-15% of questions under objective 3.2 (Security Threats). You must understand not only how to configure them in the Microsoft 365 Defender portal but also the underlying DNS record mechanics, authentication flow, and common misconfigurations that lead to deliverability failures.
Jump to a section
Imagine a company sending physical mail. SPF is like publishing a list of authorized couriers (e.g., FedEx, UPS) that are allowed to deliver mail on behalf of the company. When a recipient receives a package, they check the courier's ID against the published list. If the courier isn't on the list, the package is suspicious. DKIM is like a tamper-evident seal and a signature on the envelope. The sender uses a private key to sign the envelope, and the recipient uses a public key published in DNS to verify the signature. If the seal is broken or the signature doesn't match, the letter may have been altered. DMARC is like a recipient's policy for handling mail that fails SPF or DKIM. It tells the receiving post office what to do: deliver, quarantine, or reject. It also allows the sender to receive reports about mail that fails authentication, so they can monitor for abuse. Together, these three protect against forged mail, just as a company would control couriers, seal envelopes, and set handling rules to prevent fraud.
What Are SPF, DKIM, and DMARC?
SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) are email authentication protocols that work together to verify that an email message claiming to come from your domain actually originated from an authorized server. They are defined in RFC 7208 (SPF), RFC 6376 (DKIM), and RFC 7489 (DMARC). Microsoft 365 uses these to protect against phishing, spoofing, and business email compromise (BEC).
How SPF Works
SPF allows a domain owner to publish a list of IP addresses that are authorized to send email on behalf of that domain. This list is stored as a TXT record in DNS. When a receiving mail server gets an email, it checks the envelope sender domain (the Return-Path or MAIL FROM) and queries DNS for the SPF record. It then compares the sending server's IP against the list. If the IP is not listed, the message fails SPF. The receiving server can then apply its own policy (e.g., reject, quarantine).
SPF record syntax: v=spf1 include:spf.protection.outlook.com -all
- v=spf1 indicates the version.
- include: includes IP ranges from another domain (e.g., Microsoft's sending IPs).
- -all means fail (reject) all other IPs. ~all means softfail (mark as suspicious). +all means pass all (never use).
Microsoft 365 automatically adds an SPF record for your domain when you add it to the tenant. However, you must update it if you use third-party email services (e.g., SendGrid, Mailchimp).
How DKIM Works
DKIM uses public-key cryptography to sign outgoing emails. The sending server signs the email headers (e.g., From, Subject) and body with a private key. The receiving server retrieves the public key from a DNS TXT record in the domain's DNS zone. It then verifies the signature. If the signature matches, DKIM passes.
Microsoft 365 automatically enables DKIM for custom domains. The public key is published in DNS as a CNAME record pointing to Microsoft's key. For example: selector1._domainkey.contoso.com CNAME selector1-contoso-com._domainkey.contoso.onmicrosoft.com. Microsoft manages the private key rotation every 6 months.
How DMARC Works
DMARC builds on SPF and DKIM. It allows a domain owner to publish a policy in DNS that tells receiving mail servers what to do with messages that fail SPF or DKIM. It also enables reporting to monitor authentication results.
DMARC record syntax: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@contoso.com
- v=DMARC1 indicates version.
- p= policy: none, quarantine, or reject.
- rua= email address for aggregate reports.
- ruf= email address for forensic reports (optional).
- pct= percentage of messages to apply policy to (default 100).
- sp= subdomain policy (if different from domain).
DMARC alignment checks that the domain in the From header aligns with the domain in the SPF check (envelope domain) or the DKIM signature domain (d=). Alignment can be strict (exact match) or relaxed (organizational domain match). For example, if the From header is news@marketing.contoso.com and SPF passes for contoso.com, alignment is relaxed if the organizational domain matches.
Interaction Between SPF, DKIM, and DMARC
DMARC requires either SPF or DKIM to pass AND align. If both fail, DMARC fails. The receiving server then applies the DMARC policy. For example:
A phishing email spoofs ceo@contoso.com. It fails SPF because it's sent from a rogue IP. DKIM is absent. DMARC policy is p=reject. The receiving server rejects the email.
A legitimate email from a third-party marketing service (e.g., Mailchimp) sends on behalf of contoso.com. SPF may fail if Mailchimp's IP is not in Contoso's SPF record. But DKIM passes if Mailchimp signs with Contoso's domain. DMARC passes if DKIM aligns. So the email is delivered.
Configuration in Microsoft 365
SPF: Add or update your SPF TXT record in your DNS hosting provider. For Microsoft 365 only: v=spf1 include:spf.protection.outlook.com -all. If using third-party services, add their include statements.
DKIM: In the Microsoft 365 Defender portal (Email & Collaboration > Email > DKIM), enable DKIM for each custom domain. Microsoft will generate the CNAME records for you. You must add them to your DNS.
DMARC: Publish a DMARC TXT record in DNS. Start with p=none to monitor, then move to p=quarantine, then p=reject. Use rua to receive reports.
Verification Commands
Use nslookup or dig to verify DNS records:
nslookup -type=TXT contoso.com
nslookup -type=TXT _dmarc.contoso.com
nslookup -type=CNAME selector1._domainkey.contoso.comIn Microsoft 365, you can use the Exchange Online PowerShell:
Get-SPFRecord -Domain contoso.com
Get-DkimSigningConfig -Identity contoso.com
Get-DmarcRecord -Domain contoso.comCommon Pitfalls
Missing SPF include for third-party senders: Causes legitimate emails to fail SPF and potentially DMARC.
SPF too many DNS lookups: SPF allows a maximum of 10 DNS lookups (including includes, redirects, and mechanisms). Exceeding this causes a PermError.
DKIM selector not published: If the CNAME record is missing, DKIM validation fails.
DMARC policy too strict too quickly: Start with p=none to avoid blocking legitimate email.
Not monitoring DMARC reports: Without reports, you cannot detect spoofing or misconfigurations.
Exam Relevance
The MS-102 exam tests your ability to configure and troubleshoot these records. You may be given a scenario where email is being spoofed or legitimate email is being rejected. You must identify which record is missing or misconfigured. Know the default values, the maximum number of SPF lookups (10), and the DMARC policy levels (none, quarantine, reject).
Publish SPF Record in DNS
Create a TXT record for your domain (e.g., contoso.com) with the SPF syntax. Include the Microsoft 365 sending IPs via `include:spf.protection.outlook.com`. Add any third-party email service includes. End with `-all` to reject all other senders. The record must be under 255 characters per string, but can use multiple strings. After publishing, verify with `nslookup -type=TXT contoso.com`. This step authorizes legitimate senders.
Enable DKIM in Microsoft 365
In the Microsoft 365 Defender portal, navigate to Email & Collaboration > Email > DKIM. Select the custom domain and click 'Enable'. Microsoft generates two CNAME records (one for each selector) that you must add to your DNS. These records point to Microsoft's DKIM public key. After adding them, click 'Enable' again. DKIM signing is now active for all emails from that domain. Microsoft rotates the keys every 6 months automatically.
Publish DMARC Record in DNS
Create a TXT record for `_dmarc.contoso.com`. Start with a monitoring policy: `v=DMARC1; p=none; rua=mailto:dmarc@contoso.com`. This tells receivers to send aggregate reports but take no action. After a few weeks, analyze reports to identify legitimate senders. Then move to `p=quarantine` and eventually `p=reject`. Include `pct=100` to apply to all messages. Verify with `nslookup -type=TXT _dmarc.contoso.com`.
Monitor DMARC Reports
Aggregate reports are sent daily to the `rua` address. Use a DMARC analysis tool (e.g., Microsoft's built-in reports in Defender, or third-party services) to parse the XML reports. Look for failed authentication attempts from unknown IPs. Identify legitimate senders that need to be added to SPF or DKIM. Adjust policy gradually. Forensic reports (`ruf`) contain sample messages but are less commonly used due to privacy concerns.
Test and Validate Configuration
Send test emails from various sources: Microsoft 365, third-party services, and external systems. Use email test tools like MXToolbox or Microsoft's Remote Connectivity Analyzer. Check headers for SPF, DKIM, and DMARC results. For example, `Authentication-Results: spf=pass smtp.mailfrom=contoso.com; dkim=pass header.d=contoso.com; dmarc=pass header.from=contoso.com`. Ensure alignment passes. If any fail, troubleshoot DNS records or configuration.
Scenario 1: Large Enterprise with Multiple Third-Party Senders
A company uses Microsoft 365 for internal email but also sends marketing emails via Mailchimp and transactional emails via SendGrid. Initially, the SPF record only included Microsoft. Legitimate emails from Mailchimp and SendGrid failed SPF, and if DMARC policy was p=quarantine or p=reject, they were blocked. The solution: add include:servers.mcsv.net and include:sendgrid.net to the SPF record. Additionally, configure DKIM for both third-party services using their respective domain keys. Ensure DMARC alignment is relaxed (default) so that DKIM from these services (which sign with the company's domain) aligns. Monitor DMARC reports to catch any unauthorized senders.
Scenario 2: Phishing Attack Using Spoofed Domain
An attacker spoofs the CEO's email address (ceo@contoso.com) to request wire transfers. The company had no DMARC policy. The receiving mail server (e.g., Gmail) had no instruction and delivered the email. After implementing DMARC with p=reject, the spoofed emails are rejected because they fail SPF (rogue IP) and DKIM (no signature). DMARC reports show the attacker's IP, allowing the security team to block it. The company also sets up a mailbox for DMARC reports and uses a third-party service to analyze them.
Scenario 3: Misconfiguration Causing Legitimate Email Rejection
A company implements DMARC with p=reject but forgets to add its third-party email service (e.g., a CRM system) to SPF. The CRM sends emails on behalf of the domain but uses its own IP. These emails fail SPF and have no DKIM signature, so DMARC fails and they are rejected. The company loses important customer communications. The fix: add the CRM's IP range to SPF or configure DKIM for the CRM. This highlights the importance of starting with p=none and monitoring before enforcing reject.
MS-102 Objective 3.2: Security Threats
This chapter directly supports objective 3.2: 'Implement and manage email security'. The exam expects you to:
Configure SPF, DKIM, and DMARC records in DNS.
Enable DKIM signing in Microsoft 365.
Interpret authentication results in email headers.
Troubleshoot email deliverability issues related to these protocols.
Common Wrong Answers
'SPF checks the From header domain' – Wrong. SPF checks the envelope sender (Return-Path or MAIL FROM), not the From header. DMARC alignment bridges this gap.
'DKIM requires a TXT record with the private key' – Wrong. The private key is kept on the sending server. The DNS record contains the public key.
'DMARC policy of p=none means no protection' – Partially wrong. It means no action is taken, but it still enables reporting. It is a valid step in a phased rollout.
'You can have unlimited SPF lookups' – Wrong. The limit is 10 DNS lookups. Exceeding causes PermError and SPF to fail.
Numbers and Values to Memorize
SPF maximum DNS lookups: 10.
DMARC policies: none, quarantine, reject.
DKIM key rotation: every 6 months (Microsoft managed).
SPF record must be a TXT record; DKIM uses CNAME records; DMARC uses TXT record with prefix _dmarc.
Default DMARC alignment: relaxed (r=).
Edge Cases
Subdomains: DMARC can have a separate subdomain policy (sp=reject). If not set, the domain policy applies.
SPF macros: Rarely used but can be tested (e.g., %{i} for sender IP).
DKIM selector rotation: Microsoft uses two selectors (selector1 and selector2) to allow overlap during rotation.
DMARC forensic reports: ruf is optional and less common due to privacy issues.
How to Eliminate Wrong Answers
If a question asks about 'which record prevents spoofing', the answer is DMARC because it provides an actionable policy. SPF and DKIM are authentication mechanisms, not policies.
If a question involves 'email being rejected', check if DMARC policy is set to reject. If not, rejection is due to receiving server's own policy.
If a question mentions 'third-party sending service', ensure SPF includes that service and DKIM is configured. The most common mistake is missing SPF include.
SPF uses a TXT record to authorize sending IPs; DKIM uses a CNAME record for public key; DMARC uses a TXT record with _dmarc prefix.
SPF has a hard limit of 10 DNS lookups; exceeding causes PermError.
DMARC policies: none (monitor), quarantine (spam), reject (block).
DKIM in Microsoft 365 uses two selectors for key rotation every 6 months.
DMARC alignment checks that the From header domain matches SPF or DKIM domain.
Always start DMARC with p=none to avoid blocking legitimate email.
Third-party senders must be included in SPF or use DKIM signing with your domain.
These come up on the exam all the time. Here's how to tell them apart.
SPF
Authenticates the sending server IP address.
Uses a TXT record in DNS listing authorized IPs.
Fails if the sending IP is not in the list.
Checks the envelope sender (MAIL FROM) domain.
Does not protect email content from tampering.
DKIM
Authenticates the message content and headers using a digital signature.
Uses a CNAME record in DNS pointing to a public key.
Fails if the signature is missing or invalid.
Checks the domain in the d= tag of the DKIM signature.
Protects against content tampering during transit.
Mistake
SPF checks the From header domain.
Correct
SPF checks the envelope sender domain (Return-Path), not the From header. DMARC alignment is needed to tie the From header to SPF or DKIM.
Mistake
DKIM requires the private key to be published in DNS.
Correct
Only the public key is published in DNS. The private key is kept on the sending server and used to sign outgoing emails.
Mistake
DMARC p=none provides no protection.
Correct
p=none means no action is taken on failed messages, but it still enables reporting. It is a recommended starting point to monitor authentication results before enforcing a stricter policy.
Mistake
SPF records can have unlimited include statements.
Correct
SPF has a limit of 10 DNS lookups (including includes, redirects, and mechanisms). Exceeding this causes a PermError, causing SPF to fail.
Mistake
Enabling DKIM in Microsoft 365 automatically adds DNS records.
Correct
Microsoft generates the CNAME records, but you must manually add them to your DNS zone. DNS is not updated automatically.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The maximum is 10 DNS lookups, as defined in RFC 7208. This includes all mechanisms that generate DNS queries: include, a, mx, ptr, exists, and redirect. If exceeded, SPF returns a PermError, which typically causes the email to fail SPF. To avoid this, consolidate IP ranges or use IP4/IP6 mechanisms instead of multiple includes.
Go to the Microsoft 365 Defender portal (Email & Collaboration > Email > DKIM). Select the custom domain and click 'Enable'. Microsoft provides two CNAME records that you must add to your DNS. After adding them, click 'Enable' again. The DKIM signing will be active for all outgoing emails from that domain. Verify with `Get-DkimSigningConfig -Identity contoso.com` in Exchange Online PowerShell.
p=quarantine instructs the receiving server to treat the email as suspicious (e.g., send to spam folder). p=reject tells the server to reject the email outright (bounce). The choice depends on your confidence in your email authentication. Start with p=none, then p=quarantine, then p=reject after monitoring reports.
Yes, but DMARC requires at least one of SPF or DKIM to pass and align. If neither passes, DMARC fails. So DMARC without SPF or DKIM provides no benefit. You must have at least one authentication mechanism in place.
Alignment means the domain in the From header must match the domain used in SPF (envelope domain) or DKIM (d= domain). It can be strict (exact match) or relaxed (organizational domain match). For example, if From is user@marketing.contoso.com and SPF passes for contoso.com, alignment is relaxed. If strict, it would fail.
Aggregate reports are sent to the email address specified in the rua tag. They are XML files containing authentication results. You can use Microsoft's built-in DMARC report viewer in Defender, or third-party tools like DMARC Analyzer, Valimail, or Agari. Analyze reports to identify legitimate senders and spoofing attempts.
The SPF check returns a PermError, and the email fails SPF. This can cause legitimate emails to be rejected or marked as spam. To fix, reduce the number of includes by using IP4/IP6 mechanisms for individual IPs, or consolidate multiple includes into a single include that covers all IPs.
You've just covered SPF, DKIM, and DMARC Configuration — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.
Done with this chapter?