A working website does not prove that email is configured correctly. Website traffic and email delivery use different DNS records, and they may be managed by different companies. If a site loads but email fails, check the MX records for incoming mail first, then check SPF, DKIM and DMARC for messages sent from the domain.
DNS is only part of the diagnosis. A correct record cannot repair a suspended mailbox, an expired email subscription, a wrong password or an outage at the mail provider. The quickest route to an answer is to identify whether receiving, sending or authentication is failing before changing anything.
Start by separating receiving from sending
“Email is not working” can describe several different faults. The symptom determines which records and services deserve attention.
| Symptom | Check first | Likely place to investigate |
|---|---|---|
| Nobody can send mail to your domain | MX records, nameservers and mailbox status | DNS host and email provider |
| You can receive mail but cannot send | Mail account, SMTP settings and provider status | Email provider |
| Sent messages are rejected or placed in spam | SPF, DKIM, DMARC alignment and the rejection message | Email provider or sending platform |
| Mail stopped after a DNS or hosting change | Nameservers and the active DNS zone | Registrar and DNS host |
| Only one address fails | Mailbox, alias, forwarding rule or licence | Email provider |
Test incoming and outgoing mail separately. Send a message from an unrelated service to the affected address, then send from the affected address to an external mailbox. Keep any delivery failure or bounce message because its status code and explanation often identify the failing system.
MX records control incoming email
Mail exchange, or MX, records tell sending mail servers where to deliver messages for a domain. Each record contains a mail-server hostname and a preference number. Lower numbers are tried before higher numbers, while records with equal preference can share delivery traffic. This delivery process is defined in the SMTP standard.
A typical result might look like this:
10 mail1.example.net
20 mail2.example.net
The hostnames and priorities must match the configuration supplied by your email provider. Do not copy MX records from another domain, even if both domains appear to use the same service.
No MX result needs careful interpretation. SMTP has a historical fallback that can try the domain's A or AAAA address when no MX record exists, but a domain intended to receive modern hosted email should normally publish the provider's explicit MX records. A record shown as 0 . is different: it is a null MX, which deliberately states that the domain does not accept email.
If the expected MX records are missing, first confirm that you are editing the DNS zone used by the domain's current nameservers. Updating an old zone at a previous host has no effect on public DNS.
SPF describes who may send for the domain
Sender Policy Framework, or SPF, is normally published as a TXT record beginning with v=spf1. It describes which systems are authorised to send email using a domain in the SMTP envelope. The record format and evaluation rules are specified in RFC 7208.
SPF affects outgoing authentication, not where incoming mail is delivered. A missing or incorrect SPF record will not normally explain why a mailbox cannot receive messages. It can, however, contribute to sent mail being rejected or treated as suspicious.
Check that every legitimate sender is covered. That may include your main email platform, website contact form, invoicing system, CRM and newsletter service. At the same time, remove services that no longer send for you.
A domain should publish one SPF policy for a given name. Adding a second v=spf1 TXT record rather than combining the authorised services can create a permanent SPF error. SPF evaluation also limits the number of DNS-querying mechanisms, so repeatedly adding include entries is not a safe long-term fix. Follow the record supplied by each sending provider and ask for help if the combined policy becomes difficult to audit.
DKIM proves that a message was signed
DomainKeys Identified Mail, or DKIM, adds a cryptographic signature to outgoing messages. The receiving system retrieves a public key from DNS and uses it to verify that the signed parts of the message have not changed since the sender applied the signature. RFC 6376 defines the signing and verification process.
DKIM records are stored under a selector-specific hostname such as:
selector1._domainkey.example.com
The selector is chosen by the email provider and appears in the message's DKIM-Signature header. It cannot be discovered reliably by checking the root domain alone. For that reason, Domain Readout does not currently claim to find every DKIM key. Use the selector shown in your provider's administration panel or inspect the headers of a message sent from the affected system.
If DKIM is missing or failing, generate or enable the key with the sending provider, publish the exact DNS record it supplies, and then complete any verification step in that provider's control panel.
DMARC connects authentication to the visible From address
DMARC uses SPF and DKIM results, but also checks whether an authenticated domain aligns with the domain visible in the message's From address. A DMARC record is normally a TXT record at _dmarc.example.com, as described in RFC 7489.
Its policy can request one of three broad treatments:
p=noneasks receivers to monitor without requesting quarantine or rejection.p=quarantineasks receivers to treat failing messages as suspicious.p=rejectasks receivers to reject messages that fail DMARC.
DMARC can pass when an aligned SPF result or an aligned DKIM signature passes. Publishing a strict policy before identifying every legitimate sender can block genuine mail from services that have not been configured correctly. A staged rollout usually begins with monitoring and reporting, followed by enforcement after the results have been reviewed.
Current Gmail sender guidance requires SPF or DKIM for all senders to personal Gmail accounts. Senders exceeding 5,000 messages per day to Gmail accounts must meet additional requirements, including SPF, DKIM and DMARC. Passing these checks still does not guarantee inbox placement because delivery systems also consider factors such as sending behaviour, reputation and recipient feedback.
Check the domain in a practical order
Use this sequence before making DNS changes:
- Confirm the affected domain and address. A problem with one alias or mailbox is unlikely to be a domain-wide DNS failure.
- Check the live nameservers. Make sure the domain is using the DNS provider whose control panel you are editing.
- Compare the MX records with the email provider's instructions. Look for missing hosts, spelling errors and obsolete records from a previous service.
- Check the mailbox and subscription. Confirm that the user, licence, storage quota and service status are healthy.
- Review SPF for every sending system. Keep one policy and remove services that are no longer used.
- Verify DKIM using the correct selector. The selector must come from the sending service or a real message header.
- Read the DMARC policy and reports. Do not move directly to
p=rejectuntil legitimate mail passes with alignment. - Use the delivery error. A specific rejection message is more useful than assuming every delay is “DNS propagation”.
You can run a domain lookup and open Live DNS records to inspect the public MX, TXT, SPF, DMARC and nameserver results together. Compare those results with the records specified by your email provider rather than changing values based on appearance alone.
Know which provider can fix the problem
The company hosting the website may not host the email or DNS. Contacting the right provider saves time:
- The registrar manages the domain registration and usually controls which nameservers are delegated.
- The DNS host controls the zone containing MX, TXT and DMARC records.
- The email provider controls mailboxes, SMTP access, DKIM signing and much of the sending configuration.
- A third-party sending platform controls messages sent by newsletters, support systems, websites or business applications.
Our guide to registrars, registries and registrants explains the registration roles in more detail. If the live DNS records are correct but mail still fails, the bounce message and the email provider's logs are usually the best next evidence.
Sources and further reading
- IETF RFC 5321: Simple Mail Transfer Protocol and MX delivery
- IETF RFC 7505: Null MX records for domains that accept no mail
- IETF RFC 7208: Sender Policy Framework
- IETF RFC 6376: DomainKeys Identified Mail signatures
- IETF RFC 7489: Domain-based Message Authentication, Reporting and Conformance
- Google: Email sender guidelines