SPF, DKIM, and DMARC: How to Protect Your Business Email Domain

Sender Policy Framework (SPF) checks whether a sending IP address is authorised for the SMTP envelope sender's domain, also called the MAIL FROM domain. That domain can differ from the visible From address. SPF alone does not authenticate the address your recipient sees.

Example for a domain sending only through standard Microsoft 365:

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

-all produces an SPF fail for sources that did not match an earlier mechanism. It does not guarantee rejection: the receiver decides how to use that result. Microsoft recommends this setting alongside DKIM and DMARC for its domains; verify your actual sending sources first. See Microsoft's SPF guidance.

Inventory each sender before editing DNS. A CRM or invoice service might use a provider-owned MAIL FROM domain or a dedicated subdomain with its own SPF record. Do not add every provider to your root SPF automatically. Follow its domain-authentication instructions and check the actual MAIL FROM and DKIM signing domain for alignment with the visible From address.

SPF evaluation permits at most 10 DNS-lookup-causing mechanisms and modifiers, including nested includes. Exceeding the limit returns permerror. Remove obsolete entries or separate appropriate sending streams; copying a provider's current IP addresses requires ongoing maintenance. Microsoft advises against flattening its changing Microsoft 365 IP ranges. See the SPF specification.

DomainKeys Identified Mail (DKIM) lets a sending system sign selected message headers and body content. The receiver checks the signature using the signing domain's DNS key. A valid signature associates that signed content with the signing domain; it does not prove a particular person sent it, that you own the server, or that the message is safe. See the DKIM specification.

For Microsoft 365, DKIM configuration involves:

1. In Microsoft Defender, open Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then the DKIM tab.
2. Select your custom domain and create DKIM keys if none exist.
3. Publish both CNAME records using the exact values shown for your tenant.
4. After Microsoft detects the records, enable signing. Send test messages to an external mailbox and inspect the authentication results and signing domain.

This configures the Microsoft 365 sending path, not every third-party service using your From address. Configure and test those services separately. Keep both selectors published, review signing after DNS or provider changes, and manage key rotation. Detection time varies; follow the current Microsoft DKIM setup and verification instructions.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) connects authentication to the visible From domain. A message passes DMARC when at least one SPF or DKIM check both passes authentication and aligns with that domain. A raw SPF or DKIM pass using an unrelated domain is insufficient. Alignment can allow related subdomains or require an exact match, depending on policy. See Microsoft's DMARC guidance.

DMARC is configured as a DNS TXT record on the _dmarc subdomain:

_dmarc.yourcompany.ca TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.ca"

This monitoring example requires your own domain and a working report destination. It is not a recommendation to replace an existing enforced policy.

Policy options (p=):

• none: Requests no DMARC-specific handling of failures. Other filtering can still block or junk a message.
• quarantine: Requests suspicious-message handling for DMARC failures, such as junk placement. The receiver chooses the disposition.
• reject: Requests rejection of DMARC failures. Receivers can apply local exceptions; it is not a universal delivery guarantee.

Enforce based on evidence, not a fixed waiting period. For a new rollout, use reporting to identify legitimate senders and resolve alignment failures before progressively enforcing. Include infrequent invoice runs and campaigns in testing. Use our DMARC enforcement sender inventory to record each service, owner, sending domain, and verification evidence.

rua= requests aggregate reports from participating receivers. Reporting coverage is incomplete, so combine reports with tests of legitimate mail. Use a monitored destination or reporting service; a destination outside your domain may require DNS authorisation. The DMARC specification describes receiver discretion and reporting.

Enforced DMARC helps receiving systems reject unauthorised use of your exact From domain. It does not stop display-name impersonation, lookalike domains, or a compromised account sending authenticated mail. Keep MFA, account monitoring, and independent verification of payment changes alongside email authentication. Microsoft explains how authentication fits into wider email protection.

Google's rules for personal Gmail accounts distinguish ordinary and bulk senders. All senders need SPF or DKIM; bulk senders need SPF, DKIM, and DMARC, with p=none permitted. Direct bulk mail must align its From domain with an authenticated SPF or DKIM domain. Other requirements include TLS and low spam complaints. Bulk marketing and subscribed messages also need one-click unsubscribe. Authentication alone does not guarantee inbox placement. Check Google's sender guidelines and its bulk-sender definition; the threshold is around 5,000 messages daily to personal Gmail accounts, counted across the same primary domain.

• AI-augmented engineering services
• Managed IT services
• Cybersecurity assessments
• Cloud and Microsoft 365

Talk to us about your project