A domain can have SPF, DKIM, and DMARC records and still allow convincing impersonation. The records may cover only the main mail platform while invoices, support tickets, forms, and marketing messages leave through other services. DKIM may sign with a vendor's domain instead of yours. DMARC may be set to monitoring indefinitely. A subdomain may follow a weaker policy than the main domain. The dashboard shows three green labels, but receiving systems have not been told to reject mail that fails to prove it represents your domain.

The remedy is not to paste stricter records into DNS and hope. Email authentication is an inventory and change-management exercise. You need to know every legitimate sender, understand which identity each standard evaluates, align those identities with the address recipients see, move enforcement in controlled stages, and keep reviewing the reports after the project ends.

The identities inside one email

An email carries more than one domain identity. The visible From address is what a person normally sees in the mail client. A separate envelope sender, sometimes shown as Return-Path after delivery, is used during transport and for bounces. DKIM adds a signing domain in its cryptographic signature. These values can be different for legitimate operational reasons.

That difference explains why SPF or DKIM passing is not enough. A bulk-mail provider can send from its authorized servers and pass SPF using the provider's own bounce domain. It can sign correctly with the provider's DKIM domain. Both checks are technically successful, yet neither proves that the provider was authorized to use your domain in the visible From address.

DMARC asks the missing question: does at least one passing SPF or DKIM identity align with the visible From domain? Alignment can be strict, requiring an exact domain match, or relaxed, allowing an organizational domain and its subdomains to align. Only after that test does the receiver apply the published DMARC policy.

SPF: authorize envelope senders

SPF is a DNS record that identifies systems permitted to send using a domain in the envelope identity. A receiver compares the connecting server with that record. This is useful, but several operational traps are common.

A domain must not publish multiple competing SPF records. Merge authorized sources into one evaluated policy. Each include, redirect, and other DNS-dependent mechanism can consume the protocol's lookup budget; deeply nested vendor records can exceed it even when the text looks short. Count evaluated lookups, not lines or characters. Avoid broad network ranges and mechanisms that authorize more infrastructure than the sender actually needs. End the record with an explicit disposition that matches the intended stage rather than leaving the result ambiguous.

SPF authenticates the envelope domain, not necessarily the visible address. Configure third-party senders to use an aligned custom bounce or return-path domain when they support it. If they cannot, aligned DKIM may provide the DMARC pass instead. Do not add a vendor to the root SPF record merely because its documentation says it sends mail; first confirm which domain it uses for the envelope and whether your record is actually evaluated.

Forwarding can break SPF because the forwarding server, not the original sender, makes the final connection. That is expected behavior, not proof that SPF is useless. DMARC requires either aligned SPF or aligned DKIM, so a valid signature that survives forwarding can preserve authentication. Receivers and forwarding systems may use additional mechanisms, but your deployment should not rely on every intermediary handling mail perfectly.

DKIM: sign with a domain you control

DKIM adds a cryptographic signature to selected headers and the message body. The receiver retrieves the public key from DNS using the signing domain and selector, then verifies that the signed content has not changed in a way that invalidates the signature. The private key remains with the sending platform.

For DMARC, the signing domain identified by the d= value must align with the visible From domain. A vendor's default signature can pass DKIM while failing alignment. Configure a custom signing domain for each legitimate sender and confirm it on messages that actually arrive, not just in the vendor setup screen.

Selectors let a domain publish more than one key. Use that capability for safe rotation: publish the new public key, configure the sender to use it, verify live mail, then remove the old key after delayed messages no longer need it. Protect private keys, limit who can change signing configuration, and replace keys when a sender relationship ends or compromise is suspected. Key length and algorithm support should follow current provider and receiver guidance; do not preserve obsolete settings merely because they still produce a pass in one mailbox.

Mailing lists, security gateways, disclaimers, and forwarding systems can modify a message after it is signed. Changes to signed headers or the body may invalidate DKIM. Test the real path, including outbound gateways and list processing, before enforcement. If an intermediary rewrites every message, correct the signing point or modification sequence rather than exempting the whole domain indefinitely.

DMARC: alignment, policy, and reporting

A DMARC record is published at the designated _dmarc name for the domain. It states the requested policy for messages that fail aligned SPF and DKIM and can provide addresses for aggregate reports. The core policies are none for monitoring, quarantine for suspicious handling, and reject for refusal.

Monitoring is a legitimate discovery stage. It is not an enforcement outcome. Under a none policy, receivers can report failures while continuing their usual disposition. That gives the domain owner a way to discover legitimate senders and identify abuse without immediately interrupting mail. The failure is leaving the domain there because nobody owns the reports or the move to enforcement.

Aggregate reports summarize authentication results by sending source and domain. They do not ordinarily provide the message body. Route them to a service or mailbox able to parse the XML, retain the useful history, and group sources without hiding raw details needed for investigation. Authorize external report destinations correctly if reports are sent to another domain. Restrict access because the metadata still describes the organization's mail ecosystem.

DMARC supports separate treatment and alignment settings, including policy for subdomains. Use them deliberately. A strong policy on example.com may not produce the intended result for a delegated or independently used subdomain. Inventory subdomains that send, those that receive only, and those that should never appear in mail. Make ownership explicit before publishing a policy that affects all of them.

Build the sender inventory before enforcement

Start with more than the mail administrator's list. Review DNS, message traces, DMARC aggregate data, accounts-payable records, procurement records, password-manager entries, identity-provider applications, help-desk and CRM settings, website forms, monitoring alerts, scanners, line-of-business applications, and interviews with finance, marketing, HR, and operations. A service may send only at renewal, year-end, or during an incident, so a quiet observation week is not enough.

For every sender, record

  • Business purpose and accountable owner.
  • Visible From domains and addresses.
  • Envelope or bounce domain and SPF configuration.
  • DKIM signing domain, selector, and key owner.
  • Sending source or provider and expected volume pattern.
  • Whether mail is transactional, bulk, person-to-person, or automated.
  • Test recipient, support contact, renewal or termination date, and removal procedure.

Retire senders with no owner or purpose. For legitimate services, prefer aligned DKIM and configure aligned SPF where practical. Separate bulk or higher-risk streams onto well-managed subdomains when that improves ownership and reputation isolation. Separation is not an excuse to weaken policy; each sending subdomain still needs authentication, monitoring, and a named owner.

Move to enforcement in controlled stages

Once legitimate sources consistently pass alignment, move from monitoring toward quarantine and reject. DMARC supports applying policy to a portion of failing traffic, but receivers ultimately decide how they honor the request, so percentage rollout is a tuning aid rather than a guarantee. Increase enforcement while watching failures, support requests, and business workflows.

Test representative messages through multiple receiving providers and paths. Include replies, forwarding, aliases, mobile clients, ticket updates, invoice delivery, calendar messages, password resets, scanned documents, website submissions, and mail sent during continuity procedures. Inspect the raw authentication results for SPF, DKIM, DMARC, and the domains used in alignment. A message landing in the inbox proves delivery, not correct authentication.

Have a rollback plan that changes the DMARC policy deliberately while the underlying sender issue is fixed. Do not respond to one delivery complaint by authorizing an entire vendor network or publishing a permissive SPF mechanism. Narrow fixes preserve the value of the control. Record DNS changes, approval, expected effect, and verification results. Respect DNS caching when sequencing changes; publish required sender records before the enforcement change depends on them.

Domains that do not send mail need protection too

Organizations often secure the primary domain but ignore parked domains, campaign domains, old brands, and unused subdomains. An attacker values a believable identity even if the organization never sends legitimate mail from it. For domains that should not send, publish an SPF policy authorizing no senders and an enforcing DMARC policy, and declare the mail-handling intent appropriately. Keep the domains renewed, protected at the registrar, and included in monitoring.

A non-sending subdomain should not inherit ambiguity just because nobody created a mailbox there. Use the DMARC subdomain policy and explicit records where delegation or provider behavior makes inheritance unclear. When a domain is retired, remove old vendor authorizations and keys. Abandoned DNS records can preserve trust in a service relationship that no longer exists.

Protect the control plane

Email authentication depends on DNS, registrar access, and third-party sender administration. Protect those accounts with strong, preferably phishing-resistant authentication. Limit who can change records, use named accounts, review changes, enable registrar or registry locks where appropriate, and maintain recovery methods that do not depend solely on the protected domain's email.

Treat new sending services as a controlled change. The request should identify the owner, domains, expected messages, SPF and DKIM requirements, test plan, data handled, and end-of-service cleanup. A marketing platform should not be allowed to weaken a root-domain policy simply because a campaign launches tomorrow. Good onboarding makes secure sending faster because the necessary information is requested once and recorded.

What DMARC does not solve

DMARC can prevent unauthenticated use of your exact protected domain when receivers enforce the policy. It does not stop display-name impersonation, a registered lookalike domain, a compromised legitimate mailbox, or misleading content sent through an authorized platform. It does not judge whether an invoice is genuine. It is one layer in business email protection.

Pair it with strong authentication for mailboxes and administrators, payment-change verification outside email, protection of registrar and DNS accounts, monitoring for suspicious rules and delegated access, and awareness of confusingly similar domains. Mail filtering and user reporting still matter. Avoid presenting a DMARC pass as proof that a message is safe; it proves a relationship between authenticated sending identity and the visible domain.

Operational checks after launch

A maintained program should be able to show

  • One accountable inventory covers every active sending service and domain.
  • Live samples from each sender pass DMARC through intended aligned SPF or DKIM.
  • The main domain and relevant subdomains publish an enforcing policy.
  • Non-sending and parked domains explicitly refuse unauthorized mail.
  • Aggregate reports are parsed, reviewed, and routed to an owner when a new source or failure appears.
  • DKIM keys and vendor relationships have rotation and removal procedures.
  • DNS and sender configuration changes require named access and leave an audit trail.
  • Delivery complaints are investigated through raw results rather than solved with broad exceptions.

Review reports continuously, with extra attention after onboarding a sender, changing a gateway, rotating keys, acquiring a domain, or ending a vendor. Establish who investigates an unknown source, who confirms whether it is legitimate, and how quickly risky authorization is removed. A report nobody is expected to act on is monitoring in name only.

The honest definition of done

The goal is not three DNS records. It is a mail ecosystem in which every legitimate sender is owned and aligned, unauthorized use of the domain receives an enforcing policy, and changes do not quietly reopen the gap. That requires cooperation across technical and business teams because many senders are purchased outside IT.

Configured carefully, SPF, DKIM, and DMARC remove a simple and credible impersonation path without changing how employees write email. The standards work together, and the operational discipline around them determines whether they continue to work. A green setup screen is the beginning of that evidence, not the end.