How to set up DMARC/DKIM/SPF for Eftsure
Eftsure's custom-domain supplier email setup needs four DNS changes: add include:spf.mandrillapp.com to your single SPF record, publish the mte1 and mte2 DKIM CNAMEs, and publish one DMARC TXT record at _dmarc. Eftsure sends these messages through Mandrill and supports a custom Return-Path, so SPF can pass with matching domains. DKIM should provide a second DMARC pass path.
Only make these changes when Eftsure sends supplier onboarding or verification mail with your domain in the visible From address. If the From address remains on eftsure.com or eftsure.com.au, Eftsure authenticates that mail and your domain needs no Eftsure SPF or DKIM records.
Change DNS only for custom-domain sending
Authorizing a sender you do not use widens your SPF scope. Confirm the intended From address and custom Return-Path with Eftsure before publishing records.
Add your domain
Eftsure documents custom-domain sending as an assisted setup rather than a public self-service domain screen. Start in the Eftsure portal, open the Help bot, and request custom sender-domain enablement for supplier emails. Give Eftsure the exact organizational domain and the From address you intend to use.
- Confirm the sender: Use noreply_verifications at your Australian or New Zealand domain as the From address.
- Create the group: Create that address as a group alias and add onboarding@eftsure.com.au as a recipient.
- Allow delivery: Permit the group to receive external mail and forward to an external address.
- Share the domain: Send Eftsure the exact domain, From address, and confirmation that the group works.
- Wait for activation: Do not switch live supplier mail until Eftsure confirms that custom-domain sending is enabled.
Eftsure domain setup instructions for the supplier email alias
Do not replace your MX records
Eftsure's help article refers to MX changes, but its published values are SPF TXT and DKIM CNAME records. Leave your existing mail-routing MX records untouched unless Eftsure supplies explicit MX values for your account.
Set up SPF
Authorize Eftsure's sending infrastructure by adding include:spf.mandrillapp.com to the existing SPF TXT record at your root domain. A domain must have one SPF record only. Merge the include into that record before its final all mechanism.
- Read first: Query the root domain's TXT records and identify its current SPF value.
- Merge once: Insert include:spf.mandrillapp.com immediately before ?all, ~all, or -all.
- Count lookups: Keep the full SPF evaluation within the ten-lookup limit, including nested includes.
- Publish safely: Use a TXT record at the root and preserve every legitimate sender already present.
SPF when Eftsure is the only senderDNS
v=spf1 include:spf.mandrillapp.com ?all
Example merged SPF recordDNS
v=spf1 include:spf.protection.outlook.com include:spf.mandrillapp.com -all
The first example matches Eftsure's published minimum. The merged example is only a pattern. Keep the mechanisms required by your actual mail sources and do not copy an unrelated include.
Eftsure supports Return-Path alignment. In a received test message, the Return-Path domain should match the organizational domain in the visible From address. SPF passing against an unrelated bounce domain does not satisfy DMARC through SPF.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Run the SPF check after DNS propagation. Confirm that one SPF record is returned, the Mandrill include is reachable, the syntax is valid, and the lookup count stays at ten or fewer.
If Eftsure cannot use your domain in the Return-Path for a particular message stream, expect SPF alignment errors. That result is acceptable only when the DKIM signature passes and its signing domain matches the visible From domain, which gives DMARC a valid DKIM path.
Eftsure SPF instructions with the required Mandrill include
Set up DKIM
Publish both Eftsure DKIM selectors as CNAME records. Replace example.com with the domain used in the visible From address. Some DNS consoles append the zone name automatically, so enter only mte1._domainkey and mte2._domainkey when the interface expects relative hostnames.
- Add mte1: Point mte1._domainkey at dkim1.mandrillapp.com.
- Add mte2: Point mte2._domainkey at dkim2.mandrillapp.com.
- Disable proxying: Publish standard DNS CNAMEs without HTTP proxying or URL forwarding.
- Check conflicts: Remove any TXT or CNAME already using either complete selector name before adding the new CNAME.
Eftsure DKIM CNAME recordsDNS
mte1._domainkey.example.com. CNAME dkim1.mandrillapp.com. mte2._domainkey.example.com. CNAME dkim2.mandrillapp.com.
A CNAME lookup for each selector must end at the matching Mandrill target. A TXT lookup at the resulting DKIM name should then return a public key. Wait for the record TTL before treating an initial missing-record result as a fault.
Correct DNS shape
- Type: CNAME for both selectors.
- Names: mte1._domainkey and mte2._domainkey.
- Targets: dkim1 and dkim2 at mandrillapp.com.
- Signing result: DKIM passes with your From domain as d=.
Common publication errors
- Wrong type: Creating TXT records instead of CNAMEs.
- Repeated zone: Appending the domain twice in the host field.
- Swapped target: Pointing mte1 to dkim2 or mte2 to dkim1.
- Stale record: Leaving an older selector value at the same name.
Eftsure DKIM instructions showing both CNAME selectors
Set up DMARC
Publish one DMARC TXT record at _dmarc.example.com. Start new deployments at p=none so Eftsure traffic can be observed without changing delivery. If your domain already uses p=quarantine or p=reject, keep that stronger policy and fix authentication without weakening it.
Starting DMARC recordDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Replace example.com with a domain and report mailbox you control before publishing. If you need a clean record, use the DMARC record generator. Keep one DMARC record only, because multiple records cause receivers to treat DMARC as invalid.
- Use the right host: Publish at _dmarc, not at the root domain.
- Route reports: Set rua to a monitored mailbox or DMARC reporting destination.
- Keep the policy: Do not lower an existing quarantine or reject policy for Eftsure.
- Require one path: DMARC passes when SPF or DKIM passes and uses a matching organizational domain.
Allow DNS propagation, then query the exact _dmarc hostname. The published result should contain one record beginning with v=DMARC1, a valid policy, and a working aggregate report destination.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The checker should return a syntactically valid policy from the correct hostname. A valid record confirms publication, but it does not prove that an Eftsure message passes DMARC. That requires a live message and its Authentication-Results header.
Send a supplier invitation to an internal test recipient after Eftsure activates the domain. Confirm dmarc=pass and record whether SPF, DKIM, or both produced that pass.
Eftsure help content confirming support for all DMARC policies
Verify and troubleshoot
Verify DNS and a real Eftsure message separately. DNS checks prove that records exist. Message headers prove that Eftsure used those records, signed with the intended domain, and passed DMARC at the receiver.
- Trigger mail: Send an Eftsure supplier onboarding or verification message to a mailbox you control.
- Open headers: Inspect Authentication-Results, Return-Path, From, and DKIM-Signature.
- Confirm SPF: Look for spf=pass and a Return-Path domain matching the From domain.
- Confirm DKIM: Look for dkim=pass and a d= domain matching the From domain.
- Confirm DMARC: Require dmarc=pass before moving the message stream into production.
The email tester is the quickest end-to-end check. Send an actual Eftsure message to the generated address so the result covers message authentication, header identity, and common delivery faults in the same test.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A good test has dmarc=pass. SPF and DKIM can both pass, but DMARC requires only one of them to pass with a matching domain. Treat a DKIM pass as essential resilience because forwarding often breaks SPF.
If the test fails, compare the failing identity with the visible From domain before changing DNS. An SPF failure tied to an unrelated domain does not justify adding more SPF includes to your domain.
|
|
|
|---|---|---|
SPF | Pass, same domain | Include or Return-Path |
DKIM | Pass, same d= | CNAME or signature |
DMARC | Pass | Both paths fail |
Expected authentication signals in a received Eftsure message
SPF fails, DKIM passes
DMARC can still pass through DKIM. Confirm that the DKIM d= domain matches the visible From domain, then ask Eftsure to check the custom Return-Path if SPF should also provide a matching path.
SPF passes, DMARC fails
The SPF-authenticated Return-Path uses a different organizational domain. Fix the custom Return-Path or restore DKIM signing with your From domain. Adding the same SPF include again will not fix this.
Get alerted when it breaks
A one-time test cannot catch a removed include, an overwritten selector, a new unauthorized source, or a sudden pass-rate drop. Continuous DMARC monitoring turns aggregate reports into source-level checks and sends alerts when the Eftsure stream changes.
For most teams, Suped is the best overall DMARC platform for this workflow. Suped is our product, and we built it to connect each failing source to a specific cause and a practical fix instead of leaving teams to inspect raw XML reports.
- Verify Eftsure: Mark the known Eftsure stream as authorized and separate it from unknown sources.
- Catch changes: Use real-time alerts for authentication failures and material volume shifts.
- Follow fixes: Use automated issue detection and source-specific steps to correct SPF, DKIM, or DMARC.
- Watch reputation: Review blocklist and blacklist monitoring beside authentication results.
- Scale oversight: Manage many domains through the MSP and multi-tenancy dashboard when required.
Use a source-specific alert baseline
Record Eftsure's normal sending volume after activation. Alert on new sending IPs, DKIM failure, loss of matching Return-Path, or DMARC failure rather than waiting for supplier complaints.
Suped also brings SPF, DKIM, DMARC, blocklist monitoring, and deliverability signals into one operational view. Its feature-rich free plan is enough to start collecting reports and establish the Eftsure baseline before policy enforcement.
Secure your domain with p=reject
Move to p=reject only after every legitimate source has a reliable DMARC pass path. For Eftsure, confirm both DKIM selectors, the SPF include, the custom Return-Path, and stable live-message results. Never lower an existing reject policy to complete this setup.
- Inventory sources: Classify every sender in DMARC reports as authorized, unknown, or unwanted.
- Fix legitimate mail: Give each approved source a stable SPF or DKIM pass with a matching domain.
- Test forwarding: Confirm DKIM survives forwarding paths where SPF commonly fails.
- Stage quarantine: Apply quarantine, watch failures for at least one normal sending cycle, and correct exceptions.
- Enforce reject: Move to reject when legitimate traffic remains authenticated and unauthorized mail is the only failing class.
DMARC enforcement stages
Use observed authentication results to decide when the next policy is safe.
Observe
p=none
Collect reports and identify every legitimate source.
Correct
Hold
Fix approved sources that lack a matching pass path.
Contain
p=quarantine
Send failing mail to spam while watching business impact.
Enforce
p=reject
Reject mail that fails both matching authentication paths.
Quarantine stageDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Reject stageDNS
v=DMARC1; p=reject; rua=mailto:dmarc@example.com
Suped is strongest at this transition because it identifies verified and unverified sources, explains the failing mechanism, and provides tailored steps to fix it. That evidence makes the decision to reject operational rather than speculative.
Use Hosted DMARC in Suped when you want policy staging without repeated DNS edits. Hosted SPF, SPF flattening, and hosted MTA-STS are available when lookup limits or transport security need the same managed workflow.
