SaaS Email DNS Setup: SPF, DKIM, DMARC and MX

Set up DNS for SaaS email to help your messages reach inboxes and let receiving mail servers verify that your domain is authorized to send them. You will publish MX, SPF, DKIM, and DMARC records using the exact values supplied by your email provider; DNS changes can take time to appear worldwide.

What You’ll Need

• Access to the DNS settings for your domain, usually at your domain registrar or DNS hosting provider.
• An active email service account and any custom-domain setup instructions from that provider.
• The domain or subdomain you intend to use for email, plus permission to change its DNS records.
• A list of other services that send mail as your domain, such as a help desk, newsletter platform, or website.

Step-by-Step

1. Choose the domain you are configuring. Decide whether mail will use the root domain, such as example.com, or a subdomain, such as mail.example.com. Your provider’s setup screen should identify the exact domain to verify. Keep in mind that DNS records for a subdomain and the root domain are separate.
2. Collect the provider’s required records. In the email service’s domain setup or authentication page, note each record’s type, host or name, value, and any priority. Providers can use different MX destinations and DKIM selectors, so do not copy values from another company’s instructions. If a value is split into several strings, enter it in the format your DNS host requests.
3. Check existing DNS before changing it. Review current MX and TXT records. MX records determine where incoming mail is delivered; replacing them can interrupt an existing mailbox service. Find all legitimate senders before creating SPF, because SPF authorizes sending sources for a domain. Save or export the existing records so you can restore them if necessary.
4. Add the MX records for incoming mail. Create each MX record exactly as the provider specifies, including the destination hostname and priority. Use the root symbol or leave the host field blank only if your DNS provider’s instructions say that represents the root domain. Remove old MX entries only when you are deliberately moving mail and have confirmed the new service is ready. Do not add MX records to a sending-only subdomain unless the provider requires them.
5. Publish one SPF record for the sending domain. SPF is a TXT record, commonly at the domain’s root, though a provider may specify a subdomain. Use the provider’s exact include or other authorization mechanism. If an SPF TXT record already exists, update and combine the authorized senders into that single record; do not create a second SPF record. Preserve existing legitimate senders, and avoid adding sources you do not recognize. SPF has a limit of 10 DNS-query-causing lookups during evaluation, so complex configurations may need review.
6. Add the DKIM record or records. DKIM is usually published as a TXT record, although some providers use a CNAME. Copy the selector and target or key exactly. The DNS name often combines the selector with ._domainkey, but follow the service’s displayed host name. Long public keys may be automatically split by your DNS interface; do not remove characters or add spaces within the key. Some services require you to enable DKIM signing after DNS verification.
7. Publish a DMARC TXT record. Add a TXT record at _dmarc for the domain being protected. A cautious starting policy is commonly p=none, which requests reports without asking receivers to quarantine or reject messages. Add a reporting address only if you can receive and review the resulting reports. Once you have confirmed that all legitimate senders pass authentication and align with the visible From domain, consider moving to p=quarantine or p=reject gradually. A stricter policy applied too early can affect valid mail.
8. Save records and wait for DNS to update. Check for spelling errors, accidental extra dots, incorrect host fields, and copied spaces. DNS providers may apply changes quickly, but cached answers can persist according to prior TTL values. Wait for the period suggested by your provider before treating a verification failure as a configuration error.
9. Verify the setup and send test messages. Use the email provider’s domain-check tool, then send a message to an address you can inspect. In the received message’s original headers, look for passing SPF, DKIM, and DMARC results. Test ordinary replies and any other systems that send as the domain. If everything passes, document the records and their purpose for future maintenance.

Common Mistakes

• Publishing two SPF records. SPF evaluation can fail when a domain has multiple SPF TXT records; merge the authorized mechanisms into one.
• Overwriting existing MX or SPF records without checking for a current mail service or other sending platforms.
• Using the wrong DNS host field. Some interfaces append your domain automatically, so entering a fully qualified name can accidentally create a duplicated domain.
• Copying an example DKIM selector, key, or MX target instead of the values generated for your own account.
• Setting DMARC to quarantine or reject before checking every legitimate sender. Messages that fail alignment may be filtered or refused.
• Assuming a green verification message means every mail stream is configured. Test newsletters, support tools, website notifications, and other services separately.

Tips

• Keep a record of each DNS change, including its date, purpose, and the provider that requested it.
• Use the email provider’s current setup instructions as the source of truth; record formats and destinations can change.
• Start DMARC monitoring before enforcing a policy. Reports can reveal forgotten services, but they are technical data and may require a reporting tool to interpret.
• Remember that SPF and DMARC apply to the domain used in the relevant mail headers, while DKIM uses a signing domain. Authentication passing by itself does not guarantee inbox placement.
• Make changes in small batches when possible, so a delivery problem is easier to trace and reverse.

Troubleshooting

The provider cannot find a record: Confirm the record type and host name, then compare the complete value character by character. Check whether the DNS interface automatically adds the domain name. Query public DNS or use a reputable DNS lookup tool to see what is currently published; allow for caching before repeating verification.

SPF fails or reports multiple records: Ensure there is exactly one SPF TXT record at the relevant domain. Combine authorized senders into it without deleting existing legitimate entries, and check that the record stays within SPF’s lookup limit. Ask a domain administrator or provider for help if the combined policy is complex.

DKIM fails: Verify the selector, record name, and key or CNAME target against the provider’s instructions. Check for a truncated key or an unintended character. Confirm that DKIM signing is enabled in the email service as well as published in DNS.

DMARC reports a failure: Review whether SPF or DKIM passes and whether at least one passing method aligns with the From domain. A service can pass SPF for its own domain without aligning with yours. Identify the sending service, configure its custom-domain authentication, and keep enforcement at monitoring level until legitimate mail is accounted for.

Incoming mail stops after an MX change: Check the MX hostnames and priorities against the provider’s instructions and confirm there are no unintended old records. If mail is still being delivered to the previous service, restore the former MX records while you investigate, provided that service remains available.

Frequently Asked Questions

Do I need SPF, DKIM, DMARC, and MX?
MX is needed to route incoming mail to a service. SPF, DKIM, and DMARC authenticate or set handling policies for outgoing mail; configure the records your provider supports and recommends.

Can I have more than one MX record?
Yes. A provider may specify multiple MX records with priorities for redundancy or routing. Use its complete list and do not add unrelated destinations.

Can a domain have more than one SPF record?
No. Publish one SPF policy per sending domain. Merge legitimate sending sources into that record rather than adding another.

How long do DNS changes take?
They may appear within minutes, but cached records can take longer to expire. The prior TTL and DNS provider affect timing, so follow the provider’s verification guidance.

Should I set DMARC to reject immediately?
Usually not. Monitor first, identify all legitimate senders, and confirm alignment. Increase enforcement in stages to reduce the chance of blocking valid messages.

Will these records guarantee my email reaches the inbox?
No. Correct DNS authentication helps receiving systems assess your mail, but delivery also depends on recipient policies, sending reputation, message content, and other factors.

Related

• Steal an Egg Private Server Cost & Options
• Storage Hunters Open World Accessories Guide
• Cape Care: Smooth & Secure Fabric Cloaks