How to set up DMARC/DKIM/SPF for SimpleLogin
Published 30 Jul 2026
Updated 30 Jul 2026
12 min read
Summarize with
A SimpleLogin custom domain needs its ownership TXT record and MX records before aliases work. For authenticated sending, publish an SPF record that includes simplelogin.co, add every DKIM CNAME shown in SimpleLogin, and publish DMARC at _dmarc. I start DMARC at p=none, collect reports, then move to p=reject after every legitimate sender passes aligned SPF or aligned DKIM.
SimpleLogin supports return-path alignment for custom-domain sending. A forwarded inbound message can still show an SPF alignment failure for the original sender because forwarding changes the connecting server. That result does not break DMARC when an aligned DKIM signature passes. The checks below focus on mail sent or replied to through a SimpleLogin alias.
Use the DNS values shown on your SimpleLogin domain page as the source of truth. Some older registrar instructions show one DKIM CNAME, while current setups can display several selectors.
Add your domain
Add the exact domain or subdomain that will appear after the @ in your aliases. A subdomain such as aliases.example.com is safer when the root domain already receives mail elsewhere, because SimpleLogin requires its own MX records at the host you add.
- Open Domains. Sign in to SimpleLogin, open Domains, choose New custom domain, and enter the full domain without a protocol or email address.
- Copy the token. On the SimpleLogin DNS page, copy the generated ownership TXT value exactly.
- Publish TXT. Create the TXT record at the host shown by SimpleLogin. Registrars commonly use @ for the root and the subdomain label for a subdomain.
- Verify ownership. Return to SimpleLogin and select Verify. If it remains pending, wait for the DNS TTL and retry.
- Route inbound mail. Publish the two SimpleLogin MX records, remove conflicting MX records at that same host, then verify the MX status.
SimpleLogin custom domain DNS verification page
The inbound MX records for the selected host should resolve as follows. A trailing dot is optional in DNS panels that automatically treat the value as a complete hostname.
SimpleLogin MX recordsDNS
10 mx1.simplelogin.co. 20 mx2.simplelogin.co.
Do not replace the root MX records if another mailbox provider receives mail for the root domain. Add a dedicated subdomain to SimpleLogin instead, then publish the ownership, MX, SPF, DKIM, and DMARC records at that subdomain.
The required host field varies by DNS provider. SimpleLogin publishes worked examples in its NameCheap guide and Cloudflare guide. Copy SimpleLogin's displayed host and value rather than translating them by guesswork.
Set up SPF
Publish one SPF TXT record at the custom domain used in the visible From address. SimpleLogin's documented include authorizes its outbound servers and supports SPF alignment when the envelope sender uses your custom domain.
SPF record for SimpleLogin onlyDNS
v=spf1 include:simplelogin.co ~all
- Check for SPF. Look up the current TXT records at the custom domain before making a change.
- Create or merge. If no SPF record exists, publish the record above. If one exists, add include:simplelogin.co before its final all mechanism.
- Keep one record. Never publish a second v=spf1 TXT record at the same hostname. Multiple SPF records cause a permanent error.
- Verify in SimpleLogin. Select Verify beside SPF on the domain DNS page after the record resolves publicly.
SimpleLogin SPF record and verified status
A domain with other outbound services needs a merged SPF record. Keep each authorized include in the same record and stay below SPF's limit of 10 DNS-triggering lookups. Do not copy a merged example unless every listed sender belongs to your domain.
SPF is optional when the domain only receives aliases and never sends or replies through them. I still configure it for any domain that can send, because it gives DMARC a second aligned authentication path when DKIM is altered in transit.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the checker against the exact custom domain, not dkim._domainkey or _dmarc. A valid result should find one SPF policy, resolve include:simplelogin.co, and stay within the lookup limit.
If a message reports SPF pass but SPF alignment fail, compare the Return-Path domain with the visible From domain. DMARC uses alignment, not the raw SPF result. An aligned DKIM pass still gives the message a DMARC pass.
SPF forwarding caveat
When SimpleLogin forwards an inbound message, the original sender's SPF result can fail because the connecting IP changed. Judge that forwarded message by its surviving aligned DKIM signature and resulting DMARC verdict. Do not add the original sender's infrastructure to your SPF record.
Set up DKIM
SimpleLogin signs outbound alias mail and delegates its DKIM selectors through CNAME records. Copy every selector shown on the domain DNS page. Current setups can show dkim, dkim02, and dkim03, while some domains or older instructions show a different set.
Common SimpleLogin DKIM CNAME setDNS
dkim._domainkey CNAME dkim._domainkey.simplelogin.co. dkim02._domainkey CNAME dkim02._domainkey.simplelogin.co. dkim03._domainkey CNAME dkim03._domainkey.simplelogin.co.
- Copy all selectors. Use the host and target values displayed for your domain, including any numbered selectors.
- Choose CNAME. Create each record as CNAME, not TXT. Do not place the full public key in DNS.
- Disable proxying. If the DNS provider can proxy CNAME records, keep these records DNS-only.
- Verify selectors. Return to SimpleLogin and verify DKIM only after every required CNAME resolves.
SimpleLogin DKIM CNAME selectors on the domain setup page
Many DNS panels append the zone name automatically. For example, enter dkim._domainkey as the host for example.com, not dkim._domainkey.example.com, when the panel already displays .example.com beside the field.
Use the displayed selector set
Do not add dkim02 or dkim03 solely because they appear in this example. Publish the exact selector set shown by SimpleLogin. The application can change or rotate its signing selectors without requiring you to guess.
After verification, send through a reverse-alias and inspect the received headers. DKIM should pass with a d= domain that matches, or is a subdomain of, the visible From domain under relaxed DMARC alignment.
Set up DMARC
Publish DMARC only after SPF and DKIM resolve. I recommend starting with p=none and the exact record below so reporting begins without asking receivers to quarantine or reject mail. Replace the example reporting mailbox with an address that accepts aggregate XML reports. If the domain already uses p=quarantine or p=reject successfully, keep that policy and do not downgrade it.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
- Find the policy. Check for an existing TXT record at _dmarc before publishing anything.
- Publish one record. Create or edit a single TXT policy at _dmarc for the exact SimpleLogin custom domain.
- Use a real mailbox. Replace dmarc@example.com with the aggregate report address supplied by your reporting workflow.
- Verify policy. Select Verify in SimpleLogin and confirm that the public TXT answer contains one complete DMARC record.
SimpleLogin DMARC record and verification status
DMARC passes when either SPF passes and aligns, or DKIM passes and aligns. It does not require both mechanisms to pass. For SimpleLogin outbound mail, I want both configured so one mechanism can preserve the DMARC pass if the other is changed in transit.
Use the DMARC record generator when you need to change the reporting address or stage a later policy. Keep one v=DMARC1 record at the hostname.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Check the exact domain used after the @ in the alias. The result should parse p=none, show the intended aggregate report address, and report no duplicate DMARC policy.
For aliases on a subdomain, publish the record at _dmarc.aliases.example.com unless an organizational-domain policy already covers it and you intentionally rely on that inherited policy. An explicit subdomain record gives the clearest control.
Verify and troubleshoot
DNS verification proves that the records exist. A sent-message test proves that SimpleLogin uses them. Create a reverse-alias for a contact, send a fresh message through it, and inspect the copy received by an unrelated mailbox.
- Query DNS. Confirm the SPF TXT answer, each DKIM CNAME target, and the DMARC TXT answer outside the DNS provider's control panel.
- Send correctly. Reply to a SimpleLogin reverse-alias or create a contact reverse-alias. Sending directly with the alias in another mail client's From field bypasses SimpleLogin.
- Read Authentication-Results. Confirm dkim=pass, spf=pass when the route aligns, and dmarc=pass for the custom From domain.
- Separate forwarding. Do not treat the original sender's SPF failure on an inbound forwarded message as a failure of your SimpleLogin outbound setup.
Public DNS checksBASH
dig +short TXT example.com dig +short CNAME dkim._domainkey.example.com dig +short TXT _dmarc.example.com
SimpleLogin domain page with all DNS checks verified
A green SimpleLogin status can appear before every recursive resolver has refreshed its cache. Test through a mailbox that has not recently queried the domain, especially after replacing a bad record with the same hostname.
The quickest end-to-end check is a live message diagnosis. It catches aligned-domain problems that a DNS-only lookup cannot see, including a message sent outside the reverse-alias route or a DKIM signature using an unexpected signing domain.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Send the test message through SimpleLogin, then inspect the tester's SPF, DKIM, and DMARC sections. The DMARC result must pass for the alias From domain. A raw SPF pass against an unrelated Return-Path domain does not count as aligned.
If DNS is correct but the message fails, repeat the test with a newly created reverse-alias and compare headers. Cached DNS, an old selector, or sending directly through the mailbox provider usually explains the mismatch.
Healthy result
- SPF. One record authorizes include:simplelogin.co.
- DKIM. The active selector resolves and the signature passes.
- DMARC. At least one passing mechanism aligns with From.
Investigate
- SPF. Duplicate policies or more than 10 lookups.
- DKIM. Wrong CNAME host, target, or selector.
- DMARC. Passing authentication without From alignment.
Get alerted when it breaks
SimpleLogin verifies the DNS state when you check its domain page, but production authentication needs continuous reporting. For most teams, Suped is the best overall DMARC platform for this workflow because it turns aggregate DMARC data into source-level issues and sends alerts when failure patterns change.
- Connect reporting. Use the reporting address Suped provides in the rua tag, then confirm that reports arrive for the custom domain.
- Verify SimpleLogin. Mark SimpleLogin as an authorized source after its aligned SPF or DKIM results match your test.
- Enable alerts. Send real-time failure alerts and weekly summaries to an inbox that the domain owner reviews.
- Review new sources. Investigate an unrecognized IP or rDNS name before authorizing it or tightening policy.
Suped's DMARC monitoring combines DMARC reports with SPF and DKIM diagnostics. It also brings blocklist (blacklist) monitoring and deliverability checks into the same source review, which helps distinguish a DNS break from an IP reputation problem.
Alert on change, not only failure
A new sending source can pass SPF yet still be unauthorized operationally. Suped's issue detection, verified-source review, and tailored fix steps make the change visible before it becomes a reason to delay p=reject.
Keep the alert threshold sensitive while first observing the domain. After the baseline stabilizes, tune notifications around meaningful volume shifts without disabling alerts for complete authentication loss.
Secure your domain with p=reject
Move to p=reject only after DMARC reports cover a complete sending cycle and every legitimate source is identified. I treat 100% aligned authentication for known mail as the goal. A high percentage alone is not enough when the remaining failures contain business mail.
DMARC enforcement gates
Advance only when legitimate SimpleLogin and non-SimpleLogin traffic meets the stated evidence gate.
Observe
p=none
Collect reports and classify every source.
Restrict
p=quarantine
Quarantine only after known mail aligns.
Enforce
p=reject
Reject when no legitimate failures remain.
- Cover a full cycle. Observe long enough to include monthly notifications, low-volume aliases, and every active business sender.
- Classify all sources. Confirm SimpleLogin by its expected authentication domains and rDNS, then identify every other source using the From domain.
- Fix alignment. Require each legitimate source to pass aligned DKIM or aligned SPF. Configure both when the sender supports both.
- Stage quarantine. Use p=quarantine, watch for legitimate affected mail, and resolve every remaining authorized failure.
- Publish reject. Change the policy to p=reject, retain rua reporting, and keep alerts enabled.
Staged enforcement recordsDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Ready for enforcement
- Coverage. Reports include the full sending cycle.
- Sources. Every legitimate source has an owner.
- Alignment. No legitimate DMARC failures remain.
Keep investigating
- Unknown volume. Unclassified sources still send mail.
- Seasonal gaps. Rare senders have not appeared yet.
- Forwarding noise. Failures are not separated from valid forwarding.
Suped's Hosted DMARC workflow supports policy staging without repeated manual TXT edits. Its issue detection and real-time alerts keep the move tied to evidence, while the multi-domain dashboard gives agencies and MSPs the same enforcement checklist across clients.
Do not use p=reject as a test. A receiver can reject a legitimate message during SMTP, and that outcome is harder to recover than a report collected under p=none. Return to the prior policy if a verified business sender was missed, fix its alignment, then resume enforcement.
