SPF, DKIM and DMARC: The Domain Owner’s Email Security Guide

Email authentication helps receiving systems assess whether a message is authorized to use a domain and whether it has been altered in transit. For a domain owner, the practical challenge is not simply publishing three DNS records. It is identifying every legitimate sender, aligning authentication with the address people see, and tightening policy without disrupting business mail.

This guide explains SPF, DKIM and DMARC in operational terms. It covers setup, subdomains, forwarding, provider migrations, reporting and common failure modes. The examples use example.com and are illustrative; replace them with values supplied for your own domain and email services.

SPF, DKIM and DMARC address different parts of email authentication:

• SPF publishes which systems are authorized to send mail using a domain in the message’s envelope sender identity.
• DKIM lets a sender attach a cryptographic signature that receiving systems can verify using a public key published in DNS.
• DMARC lets a domain owner state how receivers should handle messages that fail DMARC checks, based on SPF or DKIM passing *and* aligning with the visible From address. It also provides a way to request reports about authentication activity. [1][2][3]

They work together, but none is a complete anti-phishing or deliverability solution. Authentication cannot prevent abuse of a compromised legitimate account, protect a website from lookalike domains, or guarantee that a receiver will deliver a message to the inbox. It is one important part of a broader email-security and operations program.

A typical email has more than one domain identity. The address in the visible From: header might be billing@example.com, while the technical envelope sender used during delivery could be something like bounce@mailer.vendor.net. A message can also carry a DKIM signature associated with a domain that differs from both.

That distinction matters because SPF, DKIM and DMARC evaluate different pieces of the message:

• SPF checks whether the connecting sending system is authorized for the relevant envelope-sender domain (or, in some cases, the HELO/EHLO identity). It does not directly authenticate the visible From: address.
• DKIM verifies a signature associated with the domain identified in the signature’s d= tag.
• DMARC checks whether a message passes SPF or DKIM in a way that aligns with the domain in the visible From: header. [1][2][3]

For a recipient, the visible From address is often the most important identity cue. DMARC therefore connects authentication results to that address. A message does not pass DMARC merely because SPF or DKIM passes for *some* domain. At least one mechanism must both pass and align with the visible From domain. [3]

This is why a message can show “SPF: pass” in a diagnostic tool and still fail DMARC. The SPF-authenticated envelope domain may belong to a sending vendor rather than to the domain shown in From:. The same issue can arise when DKIM passes for a vendor’s signing domain but not for your own aligned domain.

SPF is a DNS-based policy that a receiving system can use to check whether the sending IP address is authorized by the domain found in the relevant envelope identity. The policy is published as a TXT record. [1]

A simplified example might look like this:

text example.com. TXT "v=spf1 ip4:192.0.2.10 include:_spf.mailer.example -all"

The IP address shown is from a range reserved for documentation, and the vendor name is illustrative. Do not copy this record into production. Use the SPF instructions from each real sending provider, then consolidate them into the domain’s single SPF policy.

SPF does not verify the content of a message, prove that a particular person sent it, or secure the connection with encryption. It is one signal a receiver can use when evaluating a message. It also does not, by itself, make the visible From address trustworthy. DMARC supplies the alignment requirement that connects a passing SPF result to that visible address. [1][3]

For a given domain, publish one SPF policy record beginning with v=spf1. If several services send mail for the same domain, their authorized sources belong in that policy rather than in separate SPF records. Multiple SPF records can produce an error during evaluation. [1]

Before changing SPF, make an inventory of senders. Common sources include:

• Your business email platform
• Customer relationship management (CRM) and sales tools
• Marketing automation and newsletter platforms
• Invoicing, billing and payment services
• Website forms and application-generated messages
• Support desks, ticketing systems and monitoring tools
• Recruiting, events and survey platforms
• Printers, scanners or on-premises systems that send email

The inventory should record what each service sends, which From domain it uses, which envelope-sender domain it uses, and who owns the integration. A system may send mail even if nobody on the current team remembers setting it up. Old website forms, dormant campaigns and contractor-managed tools are worth checking.

SPF evaluation has a limit on DNS-querying mechanisms and modifiers. Exceeding the limit can cause a permanent SPF error rather than a useful authorization result. [1] In practice, this can happen when a long chain of include statements expands into many additional lookups.

Avoid treating SPF as a list that can grow indefinitely. Review the record when adding a sender, and consider whether unused services can be retired. Do not use online “flattening” services or manually copied IP lists without understanding the maintenance consequences: providers can change their sending infrastructure, and a stale list may stop authorizing legitimate mail. Ask the provider how its published SPF mechanism should be used and how changes are communicated.

Other common SPF problems include:

• Publishing more than one SPF record for a domain
• Copying a provider’s example without replacing its domain or mechanism
• Using an overly broad authorization that permits systems you do not control
• Ending the record with a hard-fail mechanism before all legitimate senders are known
• Authorizing a vendor in SPF while sending from a different domain than the one where the record was published
• Forgetting that SPF is checked against the envelope identity, not simply the visible From address

A policy ending in -all expresses a hard fail for sources not otherwise authorized. That may be appropriate once the authorized senders are understood, but it is not a substitute for discovery. A stricter SPF ending will not reliably stop a phisher from using a different domain, and it does not repair a missing or misaligned DKIM signature.

With DKIM, a sending system adds a signature to a message. The signature includes a d= signing domain and a s= selector, among other information. A receiver can use the selector to find the corresponding public key in DNS and verify the signature. [2]

A simplified DNS name for a selector might be:

text selector1._domainkey.example.com

The actual TXT record is generated by the email provider and may contain a long public key. An illustrative record shape is:

text selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_PROVIDER"

PUBLIC_KEY_FROM_PROVIDER is a placeholder, not a usable key. Follow the provider’s instructions for creating a selector, publishing the key and enabling signing. The private signing key should remain under appropriate control of the service or organization responsible for signing.

DKIM does not encrypt the message. It provides a way to check whether specified message content is consistent with a signature created using a corresponding private key, and whether that signature is associated with the signing domain. [2] Some message changes can invalidate a signature, depending on what was signed and how the message was modified.

Selectors make it possible to publish and distinguish keys. A provider may supply a selector name, and an organization may use different selectors for separate systems or key rotations. Keep an internal record of:

• The selector and domain where its DNS key is published
• The service that uses it
• The person or team responsible for the integration
• Whether the service is still active
• The provider’s instructions for replacing or retiring the key

When changing providers, do not remove a selector just because a new one has appeared. Confirm that the old service has stopped signing with it and that no active mail flow depends on it. A forgotten selector is not necessarily an immediate vulnerability, but unclear ownership makes key lifecycle decisions harder.

DKIM helps with forwarding scenarios because a message can retain its signature when it is relayed. But forwarding services, mailing lists or other systems may alter a message in ways that cause verification to fail. DKIM is therefore useful, not infallible.

DMARC checks the domain in the visible From: header and asks whether SPF or DKIM passed with an aligned domain. [3]

There are two alignment modes:

• Relaxed alignment allows the authenticated domain and visible From domain to be related at the organizational-domain level.
• Strict alignment requires the domains to match exactly. [3]

For example, in relaxed mode a DKIM signing domain such as mail.example.com can align with a visible From domain of example.com. Under strict alignment, those names do not match exactly. The same general distinction applies to SPF alignment.

Relaxed alignment is often operationally easier for organizations that send from subdomains. Strict alignment can offer a narrower identity match, but it requires closer coordination of the domains used by each service. Choose deliberately, test your real traffic, and do not assume that every provider can sign or return mail using the exact domain you prefer.

A DMARC record is published under _dmarc for the domain being assessed. Its p tag requests a policy for messages that fail DMARC:

• p=none requests monitoring without asking for quarantine or rejection under the DMARC policy.
• p=quarantine requests that failing messages be treated as suspicious.
• p=reject requests that failing messages be rejected. [3]

The word “requests” is important. DMARC policy is guidance to receiving systems, not a technical command that guarantees a particular outcome at every destination. Receivers make delivery decisions under their own systems and policies.

A basic monitoring record could look like this:

text _dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r"

This is an example, not a complete deployment recommendation. Confirm syntax and reporting arrangements with your DNS provider and email-security team. The rua address requests aggregate reports, while adkim and aspf set DKIM and SPF alignment modes. In this example, r means relaxed alignment. [3]

DMARC also defines a subdomain policy tag, sp, which can specify a policy for subdomains when they do not have their own DMARC record. If sp is not specified, the organizational domain’s policy applies according to the DMARC rules. A subdomain with its own DMARC record can have a separately configured policy. [3] This makes DMARC policy planning a domain-portfolio issue, not just a single-record task.

DMARC aggregate reports can help show which sources are sending mail that claims to use your domain, and whether those sources pass SPF or DKIM and align with the visible From domain. The DMARC reporting fields and mechanisms are described in the specification. [3]

Reports are not a complete, immediate record of every message. Reporting behavior varies by receiver, and data may arrive in XML that requires processing to be useful. Reports can also show infrastructure you do not recognize, which requires investigation rather than automatic blocking. An unfamiliar source might be a legitimate vendor, a forgotten application, a misconfigured system or an unauthorized sender.

Aggregate reports may contain operationally sensitive information, including sending IP addresses, message counts and domain relationships. Decide who can access them, how they are stored, and whether a reporting service is permitted to process them. Forensic or failure reports can expose more message-level information and may not be sent by all receivers. Consider privacy and data-handling implications before requesting or forwarding such reports. [3]

The safest rollout is usually staged. Publishing a strict policy before finding all legitimate senders can cause business mail to be rejected or treated as suspicious. Conversely, leaving a monitoring policy in place indefinitely means the domain is observing problems without asking receivers to act on them.

Begin by answering four questions:

1. Which domains send email? Include the main domain, subdomains, product domains and domains used by acquired brands.
2. Which teams own sending systems? Assign a named business or technical owner to each integration.
3. Which message types are in scope? Separate employee mail, transactional mail, marketing mail and system alerts where appropriate.
4. Who controls DNS and provider accounts? Confirm access, change procedures and escalation contacts.

For domain buyers and brand teams, this is also a diligence exercise. A newly acquired domain may have a long history of newsletters, vendor connections and DNS records. Check what still sends mail before changing authentication or removing records. Ask for access to email-provider accounts and DNS management, not merely a screenshot of the current records.

Collect records and evidence from multiple places:

• Current SPF, DKIM and DMARC DNS records
• Email-provider dashboards and setup documentation
• Application configuration and integration inventories
• Message headers from representative mail types
• DMARC aggregate reports, if available
• Complaints from employees, customers or partners about missing messages

For each sender, record the visible From domain, envelope-sender domain, DKIM signing domain and the business purpose. A provider that sends only password-reset mail may need a different setup from a platform that sends marketing campaigns. Do not assume that the parent company’s employee email configuration covers every system.

Follow each provider’s current instructions. Add required SPF authorization to the correct sending domain, and enable DKIM signing with a key published under the requested selector. Then send representative messages and inspect their authentication results.

Check whether:

• SPF passes for the expected envelope domain
• DKIM passes with the expected d= domain
• At least one passing mechanism aligns with the visible From domain
• The message’s From address matches the brand and mail stream it represents

A provider dashboard showing a green check is useful, but it may only confirm that one configuration step is present. Verify actual messages too. Different products from the same provider may use different sending domains or signing settings.

Start with a monitoring policy such as p=none while collecting reports. This allows you to observe sources and alignment results without asking receivers to quarantine or reject DMARC failures. [3]

Use a defined review period that reflects your organization’s sending cycles. A business with daily transactional mail may discover routine issues quickly; an organization that sends quarterly statements, event invitations or seasonal campaigns may need to observe longer. This is an operational judgment, not a universal number of days.

For each report source, classify activity as:

• Known and correctly aligned
• Known but misconfigured
• Known, but using an unintended From domain
• Unrecognized and under investigation
• Likely unauthorized, based on evidence

Do not label every unfamiliar IP address as an attack. Cloud platforms and email vendors use shared and changing infrastructure. Identify the system and its business owner before making a DNS change or enforcing policy.

Once legitimate mail is accounted for and alignment is stable, decide whether to move from monitoring to quarantine, and later whether rejection is appropriate. DMARC includes the pct tag for requesting application of policy to a percentage of messages, but receivers’ implementation and treatment are not a substitute for testing your own mail flows. [3]

A practical decision framework is:

• Stay at monitoring if sender inventory is incomplete, reports show unresolved legitimate failures, or no one owns response and recovery.
• Consider quarantine when legitimate streams are consistently authenticated and aligned, exceptions are understood, and the organization can investigate reports of missing mail.
• Consider rejection when the organization has strong confidence in its sender inventory, has tested important mail types, and has a documented process for handling provider or configuration changes.

No policy setting removes the need for monitoring. A newly adopted tool or changed integration can introduce an authentication failure after a previously stable rollout. Review reports and operational alerts after each major sending change.

Subdomains can help separate mail streams, but they can also create gaps if nobody knows who is responsible for them. A company might send newsletters from news.example.com, application mail from notify.example.com, and employee mail from example.com. Each stream may have distinct providers, SPF requirements and DKIM selectors.

Create an explicit table for each sending domain:

| Sending identity | Business use | SPF owner | DKIM signing domain | DMARC policy | |---|---|---|---|---| | example.com | Employee mail | IT | example.com or provider-approved domain | Defined | | news.example.com | Marketing | Marketing operations | news.example.com or provider-approved domain | Defined | | notify.example.com | Product notifications | Product engineering | notify.example.com or provider-approved domain | Defined |

This table is only a planning tool. The right domains depend on the services and organizational structure.

A DMARC record on the organizational domain can specify a subdomain policy with sp. A subdomain can also publish its own DMARC record. These choices let an organization apply different policies to different mail streams, but only if the DNS records and actual From domains are understood. [3]

Avoid using a subdomain as a dumping ground for unowned services. Assign an owner, document its purpose and review whether it should continue sending. If a subdomain is retired, confirm that no application, vendor or customer workflow still depends on it before removing its mail configuration.

SPF evaluates the system that connects to the receiving mail server against the relevant envelope domain. When a message is forwarded, the forwarding server—not the original sender—may be the system connecting to the next receiver. That can cause SPF to fail for the original sender’s envelope domain. [1]

Some forwarding arrangements use Sender Rewriting Scheme (SRS) to change the envelope sender to a domain controlled by the forwarder. This may help SPF authenticate the forwarder’s rewritten identity, but that identity may not align with the message’s visible From domain. DMARC can therefore still fail unless aligned DKIM passes or another relevant condition is met.

A forwarded message can retain a valid DKIM signature if the signed content remains sufficiently unchanged. But a mailing list or intermediary may add a subject tag, footer or other modification that invalidates the signature. DKIM verification depends on the signature and the message content covered by it. [2]

When diagnosing a forwarding failure, inspect the complete authentication results from the receiving system, including the domains used for SPF and DKIM. Do not assume that a message is safe or unsafe based on one result alone. If an important workflow depends on forwarding, test it with the actual forwarding service and destination.

Authenticated Received Chain (ARC) can convey authentication assessments made by intermediaries, such as a forwarding service. Some receivers may use ARC information when deciding how to handle a message that no longer passes authentication after forwarding. It does not replace SPF, DKIM or DMARC, and it does not guarantee that a receiver will accept a message. Treat it as a potential part of the mail ecosystem, not as a reason to ignore alignment or forwarding tests.

Changing email platforms is a common cause of authentication incidents. A new provider may require a different SPF include, a new DKIM selector, a different envelope-sender domain, or changes to the visible From domain. A migration can also affect mail from systems that were not part of the main project, such as billing alerts or website forms.

Use a controlled migration plan:

1. Inventory current sending sources. Include low-volume and automated systems, not just employee mail.
2. Collect the new provider’s DNS requirements. Confirm which domain each record belongs to and whether records replace or supplement existing settings.
3. Publish the new DKIM key and configure signing. Confirm that test messages use the intended signing domain.
4. Update SPF without creating a second SPF record. Reconcile the new authorization with existing senders rather than publishing a separate policy.
5. Test representative messages. Include employee mail, transactional messages, campaigns, password resets and messages sent through forwarding paths.
6. Monitor DMARC reports during the transition. Look for old and new sources, misalignment and unexpected failures.
7. Retire old records only after the old service has stopped sending. Confirm dependencies and allow for relevant DNS and operational transitions before cleanup.

Plan for rollback. Keep a record of the previous DNS values, the time of the change, the provider contact and the person authorized to restore the earlier configuration. Rollback may restore service but will not fix a misconfigured new provider; make sure there is a clear escalation path.

The same process applies when changing CRM, newsletter, billing or website platforms. A supplier’s request to add a new SPF mechanism or DKIM key should be reviewed in the context of your existing policy. Do not let a provider’s setup guide silently become the sole record of your domain’s sending architecture.

DMARC enforcement is not a substitute for SPF and DKIM setup. It depends on aligned authentication results. First find senders, configure authentication and review reports; then consider policy changes.

A message can pass SPF or DKIM and still be malicious if an account, platform or signing system has been compromised. Authentication establishes a relationship to domains and sending systems; it does not establish that the message is honest or appropriate.

Adding an overly broad SPF mechanism may turn a failed check into a pass while granting authorization to systems that should not send for the domain. Prefer provider-documented, narrowly scoped mechanisms, and investigate why the expected sender failed.

An SPF record on example.com does not automatically cover every subdomain’s mail. DKIM keys are published under selector-specific names. DMARC policies apply according to the domain in the visible From address and the relevant DMARC records. Check the exact domain used in the message rather than assuming a parent-domain record solves every case. [1][2][3]

An organization may have a stable everyday mail flow but a poorly documented annual event system or an occasional customer statement process. Review sending cycles and business calendars before tightening policy. Ask departments directly whether they send scheduled or low-frequency mail.

Reports are evidence to evaluate, not a blind list of trusted senders. An unauthorized sender may appear in reports, and a legitimate vendor can appear in an unexpected way. Identify ownership and purpose before changing DNS.

SPF, DKIM and DMARC apply to email claims involving domains under your control. They do not stop someone from registering a similar domain, impersonating an executive on a third-party service, or exploiting a compromised account. Pair authentication with account security, user reporting, anti-phishing controls and brand monitoring appropriate to your organization.

Before changing DNS:

• [ ] List every domain and subdomain that sends mail.
• [ ] Identify the business owner and technical owner for each sending service.
• [ ] Capture current SPF, DKIM and DMARC records.
• [ ] Confirm which visible From domain each message uses.
• [ ] Check the envelope-sender domain and DKIM d= domain in real messages.
• [ ] Ensure there is only one SPF policy record per sending domain.
• [ ] Check that SPF has not grown beyond its lookup limit.
• [ ] Confirm DKIM signing is enabled and the published key matches the provider’s setup.
• [ ] Decide where DMARC reports will go and who will review them.
• [ ] Document a rollback and escalation process.

Before moving to stricter DMARC enforcement:

• [ ] Review reports over a period that covers your actual sending cycles.
• [ ] Investigate unknown sources rather than automatically authorizing them.
• [ ] Resolve legitimate SPF and DKIM alignment failures.
• [ ] Test employee, transactional, marketing and forwarded mail.
• [ ] Check subdomain policy and ownership.
• [ ] Confirm that the team can detect and respond to missing legitimate messages.
• [ ] Record the planned policy change and the person approving it.
• [ ] Continue monitoring after enforcement.

These mechanisms are often described as email security controls, but their scope is specific. They help receivers assess domain authorization, message signatures and alignment. They do not encrypt email content, guarantee inbox placement, prove a sender’s real-world identity or prevent every form of impersonation.

A domain owner should consider them alongside:

• Strong authentication for email-provider and DNS accounts
• Least-privilege access for staff and vendors
• Prompt offboarding of former employees and service providers
• Monitoring for unauthorized changes to DNS and email settings
• Secure handling of signing keys and provider credentials
• User reporting and incident-response procedures
• A separate plan for protecting domains from lookalikes and misuse

Email authentication is also not a legal determination. Organizations handling regulated or sensitive information should assess their own privacy, security and record-retention requirements with appropriate professional advice.

If you are setting up a domain for the first time, begin by selecting a small number of approved sending systems and documenting their DNS requirements. Configure SPF and DKIM for those systems, then publish a monitoring DMARC policy and establish a review process. Avoid adding services to the domain without an owner and an authentication plan.

If you already have an active domain, do not jump straight to p=reject. First find the mail flows, reconcile the SPF record, enable aligned DKIM where possible, and learn from reports. A strict policy is only as reliable as the inventory and operational process behind it.

If you are buying a domain or taking over a brand, treat email configuration as part of technical due diligence. Review DNS, identify old providers and ask which applications still send as the domain. Preserve evidence of existing configuration before making changes. A domain’s past use may not be visible from its website or registrar account.

If you are migrating providers, treat the change as an authentication project, not just a mailbox move. Verify each sender, test representative message types and monitor reports while old and new systems overlap. Retire old authorization only after confirming that the related service is no longer active.

SPF, DKIM and DMARC are most effective when treated as an operational system rather than three isolated DNS records. SPF documents authorized sending sources, DKIM provides a verifiable domain signature, and DMARC checks whether one of those mechanisms authenticates in alignment with the address recipients see. The value comes from knowing what sends mail, configuring it correctly and responding when the evidence changes.

A careful rollout starts with ownership and discovery, continues through monitoring and testing, and tightens enforcement only when legitimate mail flows are understood. Subdomains, forwarding and provider migrations deserve explicit attention because they can change the identities receivers evaluate. Even a mature setup needs periodic review as teams, tools and brands change.

The goal is not to make every message look authenticated at any cost. It is to establish a trustworthy, maintainable policy for mail that genuinely represents your domain—and to make changes in a way that protects both recipients and the business.

[1]: https://www.rfc-editor.org/rfc/rfc7208 "RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1"

[2]: https://www.rfc-editor.org/rfc/rfc6376 "RFC 6376: DomainKeys Identified Mail (DKIM) Signatures"

[3]: https://www.rfc-editor.org/rfc/rfc7489 "RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)"

[4]: https://support.google.com/a/answer/81126 "Google Workspace Admin Help: Email sender guidelines"