Understanding DNS records
shipmail requires 4 DNS records to send and receive email on your domain. This page explains what each record does, why it matters for deliverability, and how to verify your configuration.
For step-by-step setup instructions, see the domain setup guide.
Required records
MX record
| Type | Host | Value |
|---|---|---|
| MX | @ | 10 mx1.shipmail.to |
The MX (Mail Exchange) record tells other mail servers where to deliver email addressed to your domain. Without it, incoming email has nowhere to go. The number before the server (10) is the priority. Lower numbers are tried first. shipmail uses a single MX server, so the priority value does not matter in practice.
SPF record
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:spf.shipmail.to -all |
SPF (Sender Policy Framework) lists the servers authorized to send email on behalf of your domain. When a receiving server gets an email from your domain, it checks the SPF record to verify the sending server is allowed. If the server is not listed, the email may be rejected or marked as spam. The -all suffix means "reject everything not listed."
DKIM record
| Type | Host | Value |
|---|---|---|
| TXT | shipmail._domainkey | v=DKIM1; k=rsa; p=... |
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outgoing email. shipmail signs each message with a private key. The DKIM TXT record publishes the corresponding public key. Receiving servers use this public key to verify the signature, confirming the email was not altered in transit and genuinely came from your domain.
Required: DMARC record
DMARC (Domain-based Message Authentication, Reporting and Conformance) is required for ShipMail setup by default. It ties SPF and DKIM together with a policy that tells receiving servers what to do when an email fails authentication. The minimal record below is ShipMail's default recommendation. Reporting fields like rua are optional advanced settings.
| Type | Host | Value |
|---|---|---|
| TXT | _dmarc | v=DMARC1; p=reject |
DMARC policy options
The p= value in your DMARC record controls what happens to emails that fail authentication. If you are migrating from another provider and want to avoid blocking legitimate email during the transition, you can start with none and tighten later.
| Policy | Effect | When to use |
|---|---|---|
| p=none | Monitor only | No action is taken on failing emails. Use this when migrating from another provider to monitor authentication results without risking delivery. |
| p=quarantine | Mark as spam | Emails that fail authentication are delivered to the spam folder instead of the inbox. |
| p=reject | Block entirely | Emails that fail authentication are rejected outright. This is the strictest and most secure setting. |
Verify records manually
shipmail verifies records automatically, but you can check them yourself using dig (Linux/macOS) or nslookup (Windows). Replace example.com with your domain.
MX record
dig MX example.com +shortSPF record
dig TXT example.com +shortDKIM record
dig TXT shipmail._domainkey.example.com +shortOn Windows, replace dig with nslookup -type=TXT example.com (swap TXT for the record type).
How the records work together
When someone receives an email from your domain, their mail server runs two checks:
- SPF check. Did this email come from a server listed in your SPF record?
- DKIM check. Does the cryptographic signature on the email match the public key in your DKIM record?
If you have a DMARC record, it tells the receiving server what to do when either check fails: report it, quarantine it, or reject it. Both SPF and DKIM working together give your domain strong email authentication and protect against spoofing.
Common pitfalls
Multiple SPF records
DNS only allows one SPF TXT record per domain. Adding a second one (instead of merging) causes both to fail. If you use another service that requires SPF (Google Workspace, Microsoft 365, etc.), merge the include statements into a single record.
Cloudflare proxy mode on MX records
Cloudflare's orange cloud proxy only works for HTTP traffic. MX records must not be proxied. Make sure the proxy toggle is off (grey cloud) for your MX record. TXT records are never proxied.
Appending the domain to the host
Most DNS providers automatically append your domain to the host field. If your domain is example.com and you enter shipmail._domainkey.example.com as the host, the actual record becomes shipmail._domainkey.example.com.example.com. Enter just shipmail._domainkey instead.
High TTL slowing propagation
If you set a high TTL (e.g., 86400 seconds / 24 hours) on existing records, changes take longer to propagate. When adding new records, use a low TTL (300 seconds / 5 minutes) initially. You can increase it after verification.
Quotes around TXT values
Some providers (notably AWS Route 53) require TXT record values to be wrapped in double quotes. Others add quotes automatically. If verification fails, check whether your provider needs manual quoting.