Your company may send email through a mailbox provider, a website, a billing service, and a marketing platform. Each sender needs to authenticate correctly. Otherwise genuine enquiries can land in spam, and other people may find it easier to impersonate your domain.
SPF, DKIM, and DMARC solve related but different problems. This guide explains their roles and gives you a practical way to review the setup without copying an unsuitable DNS record from another business.
First, list every service that sends email
Start with an inventory. Record the service, who owns it, the visible From address, and whether it sends from your main domain or a subdomain. Include password resets, contact notifications, invoices, support tickets, newsletter campaigns, and automated reports.
Your mail application is not necessarily your mail provider. Outlook, for example, can connect to different services. Use the provider that actually sends the messages when following authentication instructions. Also identify where authoritative DNS is managed; registering a domain, hosting a website, and hosting DNS can involve three different companies.
SPF identifies authorized sending infrastructure
Sender Policy Framework checks whether the sending server is authorized for the domain used in the SMTP envelope sender, commonly associated with the Return-Path. This is distinct from the From address a person sees in their inbox. The SPF specification defines that mechanism.
Publish one SPF policy record for each applicable domain, combining its legitimate senders according to their providers' instructions. Multiple separate records beginning with v=spf1 at the same name can cause a permanent SPF error. Other unrelated TXT records may coexist normally.
SPF evaluation also limits DNS lookups. Nested provider includes count toward the ten-lookup limit for mechanisms and modifiers that require them. Adding another sender can push an existing policy over that limit. Google's SPF troubleshooting guide explains common lookup and authentication failures. Remove retired services after confirming they are no longer used; do not guess provider IP ranges to force a pass.
DKIM adds a verifiable domain signature
DomainKeys Identified Mail allows a sending service to sign selected message content and headers with a private key. The recipient retrieves the corresponding public key from DNS to verify the signature. The private key stays with the signing system; it should never be published in DNS or placed in a website repository.
A selector identifies which key to look up. Providers give you a selector and DNS records, often a TXT record or provider-managed CNAME arrangement. Use the exact values for your account and enable signing in the provider after DNS is ready. Google's DKIM setup documentation illustrates the key-generation and activation sequence for Google Workspace; other providers have their own steps.
Configure each sending service, including transactional mail from Drupal. A working DKIM signature on an employee's mailbox message says nothing about the separate service sending website notifications.
DMARC connects authentication to the visible From domain
Domain-based Message Authentication, Reporting, and Conformance adds domain alignment and a published handling policy. A message passes DMARC when at least one of these paths succeeds: SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain.
Alignment relates those authenticated domains to the visible From domain. Depending on the configured mode, they must match exactly or share the appropriate organizational domain. SPF and DKIM can each pass for a provider's unrelated domain while DMARC still fails for your business's From address. See Google's DMARC alignment explanation.
A DMARC policy can request monitoring without enforcement, quarantine, or rejection of failing messages. Receivers apply their own handling rules too. Authentication improves the evidence available to them; it does not guarantee inbox placement or stop every type of phishing.
Roll out enforcement using evidence
- Confirm that the sender inventory covers real business workflows.
- Configure SPF and DKIM for those services and test messages from each one.
- Publish an initial monitoring policy with an appropriate aggregate-report destination.
- Review reports and investigate legitimate messages that fail alignment.
- Move toward quarantine and then rejection only after resolving those failures and agreeing a rollback plan.
Follow your provider's recommended rollout guidance and allow enough observation time to include infrequent senders such as monthly invoices. Restrict access to reporting mailboxes or services because authentication reports contain operational information. Recheck the policy whenever a new service starts sending on your behalf.
Check DNS, then check real messages
For a domain you administer, these read-only queries show relevant public records. Replace example.com and selector with your actual domain and provider selector:
dig +short TXT example.comdig +short TXT _dmarc.example.comdig +short TXT selector._domainkey.example.comdig +short CNAME selector._domainkey.example.com
These commands inspect records; they do not demonstrate that a particular message passed authentication. Send a test through each service and inspect the recipient's trusted Authentication-Results header and the provider's delivery logs. Check the signing domain, selector, SPF domain, and DMARC result together.
For Drupal forms, use an authenticated address under your own sending domain as the From address. Put the visitor's validated address in Reply-To when appropriate instead of impersonating their domain. If messages are still missing, continue with our form email troubleshooting guide.
Try the SPF, DKIM, and DMARC checker or DNS health checker for an initial review. For help connecting DNS, mail delivery, and your application, explore our server support service.