Are Some of Your Emails Not Reaching Their Recipients?

A quote, invoice or important update can leave your Sent folder without appearing in the recipient’s inbox. It may have been rejected, delayed, quarantined or filtered into junk. Email authentication is one of the first things to check, alongside the delivery logs and any bounce message. Passing authentication helps, but it does not guarantee inbox placement.

Sender Policy Framework (SPF) lets a domain publish the sending systems it authorises in DNS. The check normally uses the envelope sender domain, often shown in the Return-Path, rather than the From address the reader sees. Your mail provider, website forms, invoicing system and marketing platform may use different sending routes. A missing authorised sender can cause SPF failures. Publish only one SPF policy per domain name; multiple records beginning v=spf1 cause an error. SPF also limits DNS-querying mechanisms and modifiers to 10 during evaluation, including nested includes. SPF specification.

DomainKeys Identified Mail (DKIM) attaches a digital signature to outgoing messages. The receiving system uses a public key in DNS to verify the signature over the signed headers and body. DKIM does not encrypt the email or prove that its contents are safe. Publishing a DNS record alone is not enough: the sending service must actually sign messages. In Microsoft 365, use the exact CNAME values supplied for your custom domain and enable signing; other providers may use TXT records. Microsoft’s DKIM setup guidance.

Domain-based Message Authentication, Reporting, and Conformance (DMARC) checks alignment with the domain in the visible From address. A message passes when SPF passes with an aligned envelope domain, or a valid DKIM signature uses an aligned signing domain. One aligned passing method is enough for DMARC; an unrelated provider domain passing SPF or DKIM is not enough. Relaxed alignment generally allows the same organisational domain; strict alignment requires an exact domain match.

A DMARC record can express three handling preferences for messages that fail DMARC: p=none requests no DMARC-based change to handling; p=quarantine requests suspicious treatment, such as junk placement; p=reject requests rejection. Receivers retain their own filtering decisions. A none policy is useful while investigating senders, but it does not request that impersonating messages be blocked. Aggregate reporting requires a configured rua destination and receiver participation. DMARC helps address spoofing of your domain; it does not stop lookalike domains, display-name impersonation or abuse of a compromised account. The current core DMARC standard is RFC 9989, published in May 2026.

Google requires SPF or DKIM for all senders to personal Gmail accounts. Bulk senders must use SPF, DKIM and DMARC, with alignment; its FAQ treats approximately 5,000 or more messages to personal Gmail accounts in 24 hours as bulk sending. Yahoo also requires SPF, DKIM and DMARC for bulk senders. Microsoft’s requirements cover domains sending more than 5,000 messages daily to consumer Outlook.com accounts, including Hotmail and Live. These consumer-service rules should not be described as a universal Microsoft 365 tenant rule. Lower-volume businesses still benefit from correctly configuring all three methods. Google requirements, Google bulk-sender FAQ, Yahoo requirements and Microsoft requirements.

1. 1. Test every sending service. Send a non-sensitive test from your normal mailbox, website form, invoicing platform and newsletter system to external accounts you control. In Gmail on a computer, open the message’s three-dot menu and select Show original. Look for SPF, DKIM and DMARC results. A pass confirms that message’s route, not every service your business uses. How to inspect authentication headers.
2. 2. Look up SPF. On Windows, run nslookup -type=TXT example.com, replacing example.com with the relevant sending domain. Look for v=spf1. Ask your administrator to check authorised senders and the lookup limit; merely finding a record does not prove it is correct.
3. 3. Look up DMARC. Run nslookup -type=TXT _dmarc.example.com and look for v=DMARC1 and a p= policy. For a sending subdomain, also ask your administrator to check applicable inherited policy: no record at that exact subdomain does not automatically mean DMARC is absent. Confirm who reviews any aggregate reports.
4. 4. Check DKIM using the real selector. In a received message’s DKIM-Signature, find d= (signing domain) and s= (selector). Query TXT at selector._domainkey.signing-domain, using those actual values. Follow any CNAME to its public key. There is no universal selector; your provider’s dashboard and an actual signed test are essential checks.
5. 5. Keep the delivery evidence. Save the bounce response, recipient address, sending time and message ID. Your administrator can use message trace or mail logs, while the recipient’s administrator checks quarantine. A Sent-folder entry alone does not establish delivery to the recipient.

List every legitimate service sending as your business before tightening policy. Configure and test SPF and aligned DKIM for each route. If you are starting with p=none, arrange aggregate reporting and review representative business traffic, including occasional payroll or monthly billing runs. Resolve legitimate failures before moving to quarantine or reject, and monitor afterwards. Forwarding can break SPF; modifications to signed content can break DKIM. Investigate those paths rather than assuming every failure is malicious. Microsoft’s DMARC deployment guidance.

Check recipient-side filtering, sender and IP reputation, unwanted-mail complaints, invalid addresses, sending spikes, attachment restrictions, links and content. Your email provider should also verify transport security and forward/reverse DNS where applicable. For marketing and subscribed mail, follow the receiving provider’s unsubscribe requirements as well. Authentication is a foundation, and delivery problems need evidence from the specific failed message. Google’s delivery guidance.