Email Security: How to Introduce SPF, DKIM and DMARC

01Define what authentication is meant to protect

The displayed sender name, email address and actual sending route are different things. An attacker can type your director’s name or attempt to use your company domain in the From address. Authentication helps a receiving system assess a domain associated with the message. It does not prove that a particular employee approved an invoice or that the message tells the truth.

DMARC does not eliminate fraud from lookalike domains. Someone who registers a different domain and authenticates it correctly may pass technical checks. A message sent through a compromised genuine account may also pass. Keep independent verification of bank-detail changes and strong account protection after introducing all three mechanisms.

Set a precise operational objective: reduce unauthorized use of your domain, discover unknown sending services and maintain visibility into legitimate delivery. A successful DMARC result is not a certificate of company-wide security. Protect accounts alongside the domain, for example using our guide to introducing MFA and passkeys.

02List every system sending on your behalf

Start with an inventory rather than a stricter policy. Microsoft 365 or Google Workspace may be only part of the picture. Your store, CRM, invoicing service, helpdesk, website forms and marketing platform may all send messages. A forgotten service might run only at month-end. One quiet week therefore does not necessarily represent normal operations.

For each entry, identify who can change it and who can authorize retirement. Separate production from testing. Do not authorize an unknown IP address just to remove a red warning from a report. First connect it to a real service and its owner. Our guide to application notifications and emails covers the purpose and design of those streams.

03Separate the envelope, visible address and signature

The visible From header, technically RFC5322.From, supplies the sender address normally displayed by an email client. The SMTP envelope uses another address, MAIL FROM or RFC5321.MailFrom, associated with returning delivery failures. These domains may legitimately differ when, for example, an external platform sends a newsletter.

SPF normally checks the sending server against the MAIL FROM domain, rather than directly against the visible address. DKIM uses the domain in its signature’s d= value. DMARC relates those authenticated identities to the From domain. That relationship is called alignment. Discovering that some SPF check or some signature passed is therefore insufficient.

At handover, request a real delivered message and an explanation of all three domains. A green setting in a supplier’s console does not prove what your application sends. Reply-To is another separate field for replies, not the identity DMARC uses to authenticate From. Microsoft’s documentation explains the address distinction.

04SPF authorizes sources, not message content

SPF describes which servers may use a particular domain when sending mail. A receiver compares the connecting IP address with published rules. The record belongs to the domain being checked. Adding authorization to the main company domain does not necessarily fix a stream that uses a different envelope domain.

RFC 7208 does not permit multiple separate SPF records to be selected for the same domain during a check. Adding another supplier normally requires updating the existing policy, not publishing a competing second SPF record. There is also a limit of ten evaluated DNS-lookup terms of specified types, such as include. Nested rules count too; this is not simply a count of lines in the control panel.

Exceeding that limit produces an error rather than authentication success. Review the complete dependency on suppliers, remove unused permissions and avoid unnecessarily broad authorization. Blindly replacing references with fixed IP addresses is not a lasting solution either: a provider may change its infrastructure. After a change, verify actual results and delivery, not just valid syntax.

05DKIM signs a message for a particular domain

The sending system attaches a cryptographic signature. A receiver obtains the public key from DNS and verifies the signed parts of the message. The private key stays with the signing system. DKIM associates a message with a signing domain and allows changes to protected content to be detected. It is not an employee’s personal electronic signature.

RFC 6376 separates signing from encryption. DKIM does not keep an attachment confidential or determine whether a link points to a safe website. Transport, accounts and content need their own protections. A signature may survive forwarding if the signed parts remain unchanged; adding a footer or changing the subject may break it.

For an external service, verify signing with your own domain rather than only the provider’s domain. Record the selector, key owner and rotation procedure. Prepare the new key and verify new signing before retiring the old public key. Account for messages still waiting in queues with the supplier. A successful change needs evidence from delivered messages.

06DMARC needs at least one passing, aligned method

The rule in the DMARC specification is simple: DMARC passes when SPF passes with domain alignment, or when a valid DKIM signature has domain alignment. Operating both methods is useful and may be required by a mailbox provider. The DMARC calculation itself does not require both methods to pass simultaneously.

Strict alignment requires an exact domain match. Relaxed alignment uses the same organizational domain. In an illustrative example, a From domain of example.org and a valid signature with d=example.org meet even strict alignment. Do not assume subdomains align merely because their names look related. Verify organizational-domain discovery and policies throughout the relevant hierarchy.

07A policy requests receiver handling; it does not control the internet

A DMARC policy of p=none requests monitoring without special action because of the DMARC result. It does not ensure delivery: a spam filter may reject the message for another reason. A p=quarantine policy requests suspicious treatment of failing messages, such as placement in spam. A p=reject policy requests rejection.

The final decision remains with the receiving system and the other information available to it. Do not equate DMARC fail with certain rejection, or pass with guaranteed delivery. Reports for management should distinguish authentication results from the action actually taken. That difference can reveal forwarding or a receiver’s local exception.

Assess stricter handling for each sending domain and its purpose. An invoicing subdomain with controlled sending has a different operating context from employee addresses used in discussion lists. Review policy inheritance by subdomains as well. A change to the parent domain can affect a service the person making the change did not know existed.

08Test forwarding and mailing lists before enforcement

Forwarding sends the message to the next receiver from a different IP address, so the original SPF check may fail. Rewriting the envelope may help the forwarder’s own SPF result without aligning it with the original From domain. A valid aligned DKIM signature can preserve DMARC success if the signature survives the journey.

A discussion list or security gateway may alter content and break a signature. Such a message is not necessarily fraudulent. ARC, described in RFC 8617, carries verifiable information about earlier authentication assessments through intermediaries. The receiving system must still assess the chain and its participants’ trustworthiness. An ARC header is not an automatic admission ticket.

Test actual routes: external forwarding, shared role aliases, customer gateways and mailing lists employees use. Do not solve their problems by broadly disabling checks or trusting every message from a domain. Any necessary exception needs an owner, a reason and periodic review. Testing direct delivery alone does not cover these paths.

09Use reports to make decisions, not simply to build an archive

Aggregate reports show the sources from which a receiver observed messages using your domain and how checks turned out. RFC 9990 describes source IP addresses, message counts, authenticated identities and applied policy. Reports are not a complete inventory of everything you sent or evidence that customers read it. Not every receiver supplies them.

A useful dashboard separates known authorized services, authorized services with failures and unknown sources. Each problem should have an owner and a next action. Look at individual streams as well as overall pass rates. A small number of rejected password resets can matter more operationally than a large volume of failed spoofing attempts.

Define who receives reports, who can access them and how long they are retained. Individual failure reports may contain headers or even message content, as RFC 9991 explains. Do not automatically send them to an external service. First assess necessity, data scope and recipient protection. Start with aggregate results for routine visibility. Their destination is specified by the rua tag. Verify that reports actually arrive and the tool processes them. For an external destination, also check the required authorization to receive reports.

10Base rollout on operational evidence and the current specification

Prepare the inventory, responsibilities and rollback plan. Verify SPF, DKIM and alignment using real messages. Then observe reports in monitoring mode and repair legitimate streams with failures. Choose an observation period that covers real business cycles, including month-end activity and seasonal campaigns. No fixed number of days makes every domain ready.

RFC 9989, published in May 2026, replaces the original DMARC specification. It removes the old pct parameter and changes organizational-domain discovery using DNS. An older instruction to “turn on reject for ten percent” should therefore not be treated as a universally reliable safety mechanism. Assess newer testing options against the actual systems involved.

The new specification explicitly warns against p=reject for general-purpose email domains, particularly when users participate in mailing lists. Enforcement decisions should reflect documented effects and the domain’s purpose. A stricter policy is not automatically the appropriate end state for every mail stream. Providers may continue to use different implementations, so verify observed behavior.

For an approved change, identify an available administrator and stopping criteria. Preserve previous values, account for DNS caching and monitor failures both at receiving services and within your application. Restoring a record does not recover messages already rejected. Important failed submissions need their own controlled recovery procedure.

11Distinguish provider requirements from the DMARC result

Google, Yahoo and Microsoft maintain their own sender requirements. Their rules for bulk or high-volume sending include SPF, DKIM and DMARC. Those conditions apply to particular receiving services and volume definitions, not automatically to every mailbox on the internet.

For example, a technical DMARC pass through DKIM does not itself demonstrate compliance with a provider’s separate SPF requirements. A monitoring policy may meet a service’s minimum DMARC-policy requirement without requesting that spoofed mail be blocked. Assess both questions independently: did this message pass DMARC, and did it meet the destination provider’s sender requirements?

Authentication does not replace recipient permission, list hygiene, understandable unsubscribe mechanisms or suitable content. For marketing, check unsubscribe requirements with the receiving provider. A corrected DNS record will not fix a campaign repeatedly reported as unwanted. Revisit requirements when switching sending services or materially increasing volume.

12Accept the solution and assign ongoing ownership

Handover should deliver more than a screenshot of green checks. Request evidence for the main sending routes, an exception register and an operational contact. Keep configuration and its rationale in documentation the business retains when suppliers change. Access to DNS and sending services must reflect responsibility for changes.

• Every mail stream has a known service, domain and accountable owner.
• Direct and important indirect delivery paths have verified results.
• Someone reviews reports and assigns specific failures to their owners.
• A new supplier cannot start sending without an authentication review.
• Retiring a service includes removing unnecessary permissions and keys.
• Policy changes include rollback planning and monitoring of rejected mail.

Repeat checks when introducing a campaign platform, migrating mail, modifying an application or handing over administration. Where a website sends important messages, include this work in monthly website maintenance. The purpose is to keep documentation consistent with actual sending, rather than annually confirm that three records exist.

13Common questions about SPF, DKIM and DMARC