How to set up SPF, DKIM and DMARC without breaking website email

Authenticate every service that sends email for your website before tightening the domain's rejection policy. That includes receipts, password resets, support replies and any other legitimate sending system. A single overlooked sender can make a security improvement look like an unexplained failure to deliver important messages.

SPF, DKIM and DMARC are related controls, not three interchangeable badges. Treat the work as an inventory and verification exercise first. Copying a record from another site is particularly risky because your domain may use different providers, different sending subdomains and a different path for bounced mail.

Inventory the real senders before editing DNS

List each message type, the service that sends it, the visible From address and the person responsible for the account. Send an authorized test through each path and keep its headers privately. A message sent manually from your mailbox does not test the application's receipt or password-reset service.

SPF authorizes sending systems for the envelope-sender domain used during mail delivery. DKIM adds a domain's cryptographic signature to a message. DMARC then evaluates whether an authenticated domain aligns with the domain the recipient sees in From. These distinctions are described in the DMARC specification.

A hypothetical site might send support replies through its mailbox provider and purchase receipts through a separate commerce service. Both messages can show the same brand while taking different technical routes. Verify both routes rather than assuming the mailbox provider's DNS instructions cover everything the business sends.

Record the current DNS values and who can restore them before making changes. Where providers require verification records, use the exact values they supply for your domain. Do not overwrite unrelated mail-routing records while trying to fix outbound authentication; incoming mail and sender authentication are separate concerns.

Add authentication without breaking an existing sender

The SPF specification does not permit multiple SPF records for the same domain name. When a second provider needs authorization, update the existing policy deliberately instead of adding another independent v=spf1 record. Multiple unrelated TXT records are normal; multiple competing SPF policies are the problem.

SPF evaluation also has a limit of 10 DNS-querying mechanisms and modifiers. Nested includes can consume that allowance, so counting visible provider names is not enough. Ask the responsible mail administrator to evaluate the complete policy rather than keep adding includes until a provider dashboard turns green.

For DKIM, follow each sender's key and selector instructions and then verify a message actually sent by that service. Publishing a key alone does not prove that the service has started signing with it. Keep private keys private; only the provider-designated public DNS material belongs in a shared configuration record.

Do not remove an old sending provider until you have checked whether scheduled jobs or another team still use it. A clean-looking DNS zone can hide a broken monthly invoice run. Retire authorization only after the operational dependency has been removed and the replacement has been tested.

Use DMARC reports before imposing rejection

Begin with observation when you do not yet know every legitimate sender. A DMARC policy of p=none requests no DMARC-based quarantine or rejection, while reporting can help identify authentication and alignment problems. It is a monitoring stage, not evidence that spoofed mail is being blocked.

A DMARC pass needs aligned SPF or aligned DKIM, not simply an authentication pass for any unrelated domain. Inspect the authenticated domains in a delivered test message. The visible brand name is not the alignment test, and successful delivery on one occasion is not proof that the policy is correct.

Arrange for someone to review aggregate reports and investigate unfamiliar sources before changing the policy. Protect the report destination and limit access to the operational data. A reporting address that nobody reads adds configuration without creating a useful control.

Move to stronger treatment only after legitimate sending paths pass and you have a documented rollback plan. Test again after changing a provider, a From domain or a signing configuration. The aim is to reject impersonation without making normal customer messages collateral damage.

Check recipient requirements and actual delivery

Gmail's sender guidelines require SPF or DKIM for all senders to personal Gmail accounts, and SPF, DKIM and DMARC for bulk senders. Google also addresses alignment, transport security and other delivery practices. Authentication is necessary groundwork, not a guarantee of inbox placement.

Do not apply a rule intended for bulk promotional messages blindly to every transactional message. Identify the audience, message purpose and applicable recipient requirements. Keep receipts and account notices distinct from marketing so that delivery troubleshooting does not become entangled with unrelated promotional behavior.

After deployment, verify messages from every inventoried sender and inspect any rejection notices. Keep timestamps and error details, but avoid placing credentials or private customer content in a public issue tracker. Compare the failures with the specific change rather than repeatedly editing several DNS records at once.

Add sender reviews to your website maintenance routine, and include them whenever hosting or infrastructure changes affect mail. The finish line is not three records in DNS. It is a tested list of legitimate senders, an observed policy and a clear owner for the next change.