Few things disrupt business operations faster than transactional emails landing in spam or bounce-back errors on company email addresses. With major mailbox providers like Google (Gmail), Microsoft (Outlook/Office 365), and Yahoo enforcing strict anti-spam requirements, correct DNS configuration is mandatory for reliable email deliverability.

Email delivery relies on a coordinated set of DNS records: MX records tell the internet which servers receive mail for your domain, while SPF, DKIM, and DMARC prove that outgoing emails genuinely originated from your authorized servers.

This guide explains how to configure and verify each component using an MX record lookup, a DNS record checker, and an online port check.

1. How Mail Exchange (MX) records work

When someone sends an email to [email protected], the sender mail transfer agent (MTA) queries DNS for the MX records of example.com.

An MX record consists of two parts:

1. Mail Server Hostname: The fully qualified domain name (FQDN) of the mail server (such as aspmx.l.google.com).
2. Priority / Preference Value: A numeric weight indicating the order in which servers should be contacted (lower numbers mean higher priority).

Example MX configuration for Google Workspace:

Host	Type	Priority	Target / Value
@	MX	1	aspmx.l.google.com
@	MX	5	alt1.aspmx.l.google.com
@	MX	5	alt2.aspmx.l.google.com
@	MX	10	alt3.aspmx.l.google.com
@	MX	10	alt4.aspmx.l.google.com

Sending servers attempt to deliver to the priority 1 server first. If it is unreachable or timing out, they fall back to the priority 5 and priority 10 servers.

Common Mistake: Pointing an MX record directly to an IP address instead of a hostname. RFC 2181 explicitly requires MX records to point to a valid canonical domain name (A/AAAA record), not an IP address or a CNAME.

You can verify your current MX configuration using the PingXD MX Test tool.

2. Sender Policy Framework (SPF)

SPF prevents email spoofing by publishing a list of authorized IP addresses and third-party services permitted to send email on behalf of your domain.

SPF is published as a DNS TXT record on your root domain:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.25 -all

• v=spf1: Identifies the TXT record as SPF version 1.
• include:_spf.google.com: Authorizes Google Workspace servers.
• include:sendgrid.net: Authorizes SendGrid for transactional emails.
• ip4:198.51.100.25: Authorizes a dedicated web server IP.
• -all (Hard Fail): Instructs receiving servers to reject any mail from unauthorized senders. (Alternatively, ~all indicates a Soft Fail for testing).

Crucial Rule: A domain must never publish more than one SPF TXT record. If you use multiple services (e.g., Google Workspace, Zendesk, Mailchimp), combine them into a single record. Additionally, SPF lookups cannot exceed the strict 10 DNS lookup limit.

3. DomainKeys Identified Mail (DKIM)

While SPF verifies sender IP addresses, DKIM provides cryptographic proof that the message content was not tampered with during transit.

When an email is sent, the mail server generates a digital signature using a private key and attaches it to the email header (DKIM-Signature). The receiving mail server retrieves the matching public key published in your DNS under a specific selector:

google._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE..."

If the signature decrypts successfully with the public key, the message passes DKIM verification.

4. DMARC: Policy enforcement and reporting

DMARC builds upon SPF and DKIM. It tells receiving mailbox providers what to do if an incoming message fails SPF or DKIM checks, and enables feedback reports sent to domain owners.

Published as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100;

• p=none: Monitor mode (collect reports without affecting delivery).
• p=quarantine: Direct failed messages to the recipient spam folder.
• p=reject: Direct failed messages to be blocked outright at the gateway.
• rua=mailto:...: Aggregate reports mailbox for monitoring authentication trends.

5. Reverse DNS (rDNS / PTR) & Port Reachability

Even with SPF and DKIM configured, receiving mail servers will reject emails if the sending server public IP address does not have a matching Reverse DNS (PTR) record.

For example, if your mail server sends from 198.51.100.25, an rDNS lookup for that IP must resolve back to mail.example.com, and mail.example.com must resolve forward to 198.51.100.25 (Forward-Confirmed reverse DNS).

Additionally, verify that your mail server inbound ports are reachable:

• Port 25: Standard server-to-server SMTP relay.
• Port 587: Authenticated client submission (STARTTLS).
• Port 465: SMTPS (Implicit TLS).

Test that port 25 is open and accessible from global networks using the PingXD Port Checker.

Checklist for 100% email deliverability

1. Query your domain on the PingXD MX Record Lookup tool to ensure all MX hosts resolve with valid priorities.
2. Use the PingXD DNS Lookup tool to inspect TXT records for valid SPF, DKIM (_domainkey), and DMARC (_dmarc) syntax.
3. Verify your mail server IP is not listed on major DNS blocklists (RBL/DNSBL).
4. Run a Port Check on port 25 to confirm inbound firewall rules.