How to set up DMARC/DKIM/SPF for MegaMailServers
Published 24 Jun 2026
Updated 25 Oct 2026
14 min read
Summarize with
Updated on 25 Oct 2026: We added provider-specific DNS examples and clarified SPF failures and DMARC policy testing.
MegaMailServers can be the shared outbound infrastructure behind a reseller or provider-branded hosted mailbox service. The practical authentication chain is the same: identify the account that sends the mail, confirm the visible sending domain, publish the account-specific SPF and DKIM records, publish DMARC, then verify with a real message. The exact panel labels vary, and the DNS work happens at the public DNS host for your domain.
Do not assume that every MegaMailServers-backed account exposes a custom Return-Path. Inspect a fresh message first. SPF contributes to DMARC only when the authenticated MAIL FROM domain aligns with the visible From domain. Aligned DKIM is essential because it can keep DMARC passing when forwarding or provider routing changes the SMTP envelope path.
Confirm your sending domain and DNS access
Start in the reseller mail admin or hosting panel that controls the mailbox service. Confirm that the domain after the @ in the visible From address is configured for sending. Add it if it is missing and the service supports additional domains. Keep the public DNS console open so you can publish the account records. If the panel does not expose authentication settings, ask the reseller or mailbox provider for its supported SPF, DKIM, and Return-Path values.
MegaMailServers domain administration screen with an Add domain dialog
- Open the reseller console or hosting panel that owns the mailbox service.
- Confirm the exact domain used in visible sender addresses, including a subdomain or alias domain when applicable.
- Confirm that the domain uses the intended mailbox, SMTP, MX, and outbound routing profile.
- If the account supports a custom bounce domain, configure a subdomain such as bounces.example.com and verify it in a live header.
- Make sure you can publish TXT and CNAME records where the public DNS zone is hosted.
- If the account has a domain verification action, run it after the new DNS records resolve publicly. Confirm the result with a live message.
Check these four identities
- The From domain is the domain users see in the message sender line.
- The MAIL FROM domain appears in the Return-Path and is used for SPF and delivery status notices.
- The DKIM signing domain is the domain in the d= tag of the DKIM signature.
- The report destination domain is the domain of the address that receives DMARC aggregate reports.
Check provider-specific MegaMailServers DNS records
MegaMailServers records depend on the reseller and mail cluster. Easily's published email FAQ lists the following SPF TXT value and DKIM CNAME for its hosted email service. Use them only when Easily confirms they apply to your account; other MegaMailServers services need their own values.
|
|
|
|
|---|---|---|---|
SPF | TXT | @ | v=spf1 include:spfc51.megamailservers.com ~all |
DKIM | CNAME | hmail._domainkey | hmail._domainkey.megamailservers.eu. |
Easily-published examples, not universal MegaMailServers settings
Here, @ means the root of the domain in the DNS zone. Merge the SPF include into an existing SPF record rather than replacing authorization for other senders. Use the DKIM record type supplied by your provider. Changing MX records is not required solely to publish SPF, DKIM, or DMARC.
Set up SPF
SPF (Sender Policy Framework) authorizes the outbound hosts for the domain used in the SMTP envelope. Send a message through the account and inspect its Return-Path before editing DNS. Add only the include, hostname, or IP data supplied for that reseller account. A megamailservers.com MX or PTR hostname identifies infrastructure, but it does not prove which SPF include your domain should publish.
SPF patterns, replace the provider placeholderdns
yourdomain.com. TXT "v=spf1 include:<provider-spf-host> ~all" # If the account uses a custom Return-Path instead: bounces.yourdomain.com. TXT "v=spf1 include:<provider-spf-host> ~all"
These patterns are examples, not records to copy unchanged. Replace the placeholder with the provider-approved hostname and use the actual MAIL FROM domain. In a DNS form, enter the TXT value without the zone-file hostname, TXT keyword, or surrounding display quotes.
- Use the exact SPF include, hostname, or IP range shown for your account. Do not derive it from the MX or rDNS name.
- Merge the authorization data into the existing SPF record for each MAIL FROM domain. Do not publish two SPF TXT records at the same hostname.
- Choose ~all or -all only after inventorying every sender. A hard fail can cause rejection before DMARC processing, so it is not a DMARC rollout switch.
- Keep SPF evaluation within the limit of 10 mechanisms and modifiers that cause DNS lookups, including nested includes and redirects. Exceeding it produces SPF permerror; ip4 and ip6 mechanisms do not count toward this limit.
- Publish SPF on a custom Return-Path subdomain only when the account actually uses that domain in outgoing headers.
|
|
|
|---|---|---|
Sender | Outbound source | |
MAIL FROM | Root or bounce domain | SPF identity |
Authorization | Account-provided value | Sending hosts |
Result | Pass plus alignment | DMARC path |
SPF values to collect before editing DNS
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
MegaMailServers SPF setup panel showing TXT value and Return-Path host
When SPF is not enough
If the reseller account does not expose a custom Return-Path, SPF can pass for a provider domain without aligning to your From domain. DMARC still passes when an aligned DKIM signature passes, so confirm that DKIM path before raising policy.
- Ask the mailbox provider for its supported Return-Path or envelope sender configuration.
- Make aligned DKIM pass for every MegaMailServers-backed stream before raising DMARC policy.
Set up DKIM
DKIM (DomainKeys Identified Mail) signs message headers and content and can survive forwarding. Confirm that the provider supports signing for your domain, copy the selector record supplied for the account, publish it in DNS, then verify that outbound mail carries a valid signature using your domain in the d= tag. For RSA keys, 1024 bits is the minimum; prefer 2048 bits when supported.
MegaMailServers DKIM setup screen with selector and DNS record details
DKIM TXT pattern when the provider supplies a public keydns
selector._domainkey.yourdomain.com. TXT ( "v=DKIM1; k=rsa; p=<public-key-from-MegaMailServers>" )
The mailbox provider keeps the private signing key on its sending system. Publish only its public key or the supplied CNAME delegation in DNS. Creating a DNS record alone does not enable signing, and a provider-supplied CNAME replaces the TXT pattern at that selector.
- Confirm DKIM signing support for the sending domain with the provider; enable it if the account exposes a setting.
- Use the exact selector supplied for your domain. The s= tag in a fresh DKIM-Signature header identifies the selector in use.
- Create the TXT or CNAME record exactly as supplied, without adding the domain twice in a DNS interface that appends it automatically. Do not publish both record types at the same selector hostname.
- Send a fresh email and confirm that DKIM passes with an aligned signing domain.
- Verify the new selector in live headers and retain the old public key long enough for messages already in transit to be verified before removing it.
Good DKIM setup
- The DKIM d= value aligns with your From domain.
- The selector resolves in public DNS.
- The DKIM result is pass in raw headers.
- Every MegaMailServers-backed mail stream signs with the intended domain.
Risky DKIM setup
- The DKIM d= value uses only a provider domain.
- The selector returns NXDOMAIN or an empty TXT response.
- The DNS name repeats the domain suffix, or the public key was truncated or changed.
- The account rotated DKIM, but DNS still has the retired key.
Do not enforce before DKIM passes
A p=reject DMARC policy can affect legitimate MegaMailServers-backed mail when DKIM fails and SPF does not produce an aligned domain. Get DKIM passing first, then raise policy.
Set up DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) checks the visible From domain against a passing SPF or DKIM identity. Publish its policy after configuring SPF and DKIM. If the domain is not already on p=quarantine or p=reject, start with p=none and collect reports before enforcement. RFC 9989 defines DMARC policy, while RFC 9990 and RFC 9991 define aggregate and failure reporting.
Starter DMARC TXT record for example.comdns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Replace example.com with your sending domain and the rua address with a working report destination. Aggregate reports are XML data, often compressed; use a parser or a reporting platform to review them.
Relaxed alignment is the default for aspf and adkim: the authenticated domain and From domain must share an organizational domain. With aspf=s or adkim=s, the corresponding domain must match exactly. A bounce subdomain therefore satisfies relaxed SPF alignment with its parent domain, but fails strict alignment.
Use the DMARC record generator when you need to build the record with reporting and policy options. After publishing, confirm parsing with the DMARC checker.
- Create one TXT record at _dmarc for the sending domain, such as _dmarc.example.com. Do not create a second DMARC record at the same hostname.
- Use p=none unless the domain already runs quarantine or reject. If it does, keep that policy while fixing the new sending source.
- Send rua reports to a working mailbox or a platform such as Suped that parses aggregate XML, including RFC 9990 data.
- When the rua address uses another organizational domain, confirm that the report receiver publishes the required DNS authorization.
- Add sp=none only when subdomains deliberately need a separate monitoring policy. Without sp, they normally inherit p; check for a subdomain-specific DMARC record before assuming inheritance.
- Skip ruf unless you have a defined process for RFC 9991 data. Few receivers send these reports, and they can contain message-specific information.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
MegaMailServers authentication overview showing SPF, DKIM, and DMARC status
What a pass looks like
- SPF passes for the MAIL FROM domain, and that domain aligns with the visible From domain.
- DKIM passes, and the d= value aligns with the visible From domain.
- DMARC passes when either the aligned SPF path or aligned DKIM path passes.
- Aggregate reports identify the sending source with pass, fail, alignment, and volume data.
Verify and troubleshoot
Send a new message through the MegaMailServers-backed route after every DNS change. Do not rely only on a control panel status, because cached DNS and old mail headers can hide the current state. Check authoritative DNS, then allow cached answers to expire according to the previous TTL before retesting.
- Send a new outbound email through the mailbox or SMTP route that uses MegaMailServers infrastructure.
- Read Authentication-Results added by the receiving mail system you trust, then check SPF, DKIM, and DMARC results plus the domains evaluated for each result.
- Confirm that the MAIL FROM domain aligns with the visible From domain when SPF is expected to satisfy DMARC.
- Confirm that the DKIM d= value aligns with the visible From domain.
- Review aggregate data for source IPs, pass rates, alignment failures, and unexpected senders. Reports usually arrive daily, so verify changes in the next reporting cycle.
- Confirm that each sending IP has a PTR hostname whose A or AAAA record resolves back to that IP. The infrastructure operator manages this on a shared hosted service.
- If MegaMailServers appears only in rDNS, map the source to the reseller account before changing your DNS.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Use the email tester for a direct verification path: send one live MegaMailServers-backed message to the generated test address, then read the SPF, DKIM, DMARC, DNS, and header diagnosis from the result.
Illustrative receiver Authentication-Results headertext
Authentication-Results: receiver.example; spf=pass smtp.mailfrom=bounces.example.com; dkim=pass header.d=example.com header.s=selector; dmarc=pass header.from=example.com
|
|
|
|---|---|---|
SPF fail | Sending IP is not authorized for the evaluated MAIL FROM domain | Check the SMTP route and publish the provider-approved authorization |
SPF permerror | Duplicate SPF records, excessive lookups, or invalid syntax | Keep one valid SPF record and remove unnecessary terms that cause DNS lookups |
DKIM fail | Wrong selector or key, or changes to signed content | Match selector and key; check changes after signing |
SPF pass, DMARC fail | SPF domain mismatch and no passing aligned DKIM signature | Configure a supported custom MAIL FROM domain or fix DKIM alignment |
DMARC fail | No aligned pass | Fix SPF or DKIM alignment |
DMARC pass, poor delivery | Reputation or recipient filtering | Check SMTP rejection text and provider logs |
Common MegaMailServers authentication failures
Policy readiness checks
Use these checkpoints before moving MegaMailServers-backed mail to stronger DMARC enforcement.
Collect
p=none
Reports are flowing and the sending source is visible.
Fix
open
SPF, DKIM, or domain alignment failures have owners.
Stage
quarantine
Known mail passes and indirect flows have been reviewed.
Enforce
reject
Legitimate mail passes consistently under the applied policy.
Repair the failing sender
Do not weaken DMARC because one MegaMailServers-backed stream fails. Find whether the failure is SPF authorization, identifier alignment, DKIM signing, selector DNS, or propagation, then repair that source.
Handle forwarding and aliases
Forwarding changes the connecting IP, so SPF usually fails after a message is relayed. An aligned DKIM signature can survive forwarding when the intermediary does not alter signed content. This is why a domain moving toward DMARC enforcement should not rely on SPF alone.
- Test messages sent through every automatic forwarder before applying reject policy.
- Sender Rewriting Scheme can make SPF pass for a rewritten forwarding domain, but that domain normally lacks alignment with the original From domain. The forwarding service implements SRS; it cannot be enabled with a sender-side DNS record.
- Authenticated Received Chain preserves authentication context for a receiver, but it does not change a source DMARC fail into a pass.
- If users send with an alias domain in the From header, enable aligned DKIM and publish the required selector for that alias domain.
- Review list traffic separately because subject tags, footers, or other content changes can break an original DKIM signature.
Test user mail before reject
RFC 9989 warns that p=reject can disrupt Internet mailing lists and role-based aliases. For domains whose users participate in those flows, compare aggregate report results during at least a month at p=none and an equally long period at p=quarantine before applying reject.
Monitor authentication changes
Authentication can break after DNS edits, mailbox migrations, DKIM key rotation, or provider routing changes. Suped is our DMARC reporting and email authentication platform. Its DMARC monitoring groups aggregate reports by sending source so domain owners can investigate failures without reading raw XML.
A blocklist (blacklist) listing affects reputation separately and does not change authentication results. Reports usually arrive daily, so alerts based on those reports reflect received data rather than every message in real time.
- Notify the domain owner when reports show an account failing authentication or alignment.
- Detect duplicate SPF records, DNS lookup overruns, and missing account authorization.
- Investigate unsigned mail and selector errors when DKIM pass rates drop.
- Monitor IP and domain reputation across major blocklists and blacklists.
- Manage client domains together when MegaMailServers infrastructure appears across reseller accounts.
Suped monitoring workflow
- Compare source IPs, rDNS, and DKIM domains with your account inventory; aggregate reports do not identify reseller account logins.
- Flag authentication failures, DNS errors, policy risk, and source changes.
- Apply the account-specific DNS change, verify with a fresh message, then confirm the result in later reports.
- Route authentication alerts to the domain owner as reports arrive.
Move to DMARC enforcement
Move toward p=reject only after MegaMailServers-backed mail and every other legitimate sender pass DMARC in live reports. A control panel check confirms DNS visibility, but it does not prove that every production route, alias, or forwarded message passes.
- Run p=none until all normal sending cycles appear clearly in aggregate reports.
- Separate mailbox mail, transactional mail, marketing mail, web application mail, and indirect paths.
- Fix aligned DKIM first, then repair SPF authorization and Return-Path alignment where the account supports it.
- Move to p=quarantine and review report dispositions before requesting p=reject.
- Move to reject only after reports show needed mail passing and unapproved mail failing.
DMARC policy stages, publish one value at a timedns
v=DMARC1; p=none; rua=mailto:dmarc@example.com v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com v=DMARC1; p=reject; rua=mailto:dmarc@example.com
The pct tag is historic under RFC 9989. At receivers implementing RFC 9989, t=y lowers quarantine to none and reject to quarantine for failing mail. Receivers using older implementations can ignore this tag and apply the stated policy. Use explicit policy changes for staging rather than relying on testing mode to prevent enforcement.
Before p=reject
- Aggregate data is flowing for the domain.
- The account source is identified and passing.
- Forwarding, aliases, and mailing lists have been tested.
- Full quarantine testing shows no legitimate mail loss.
After p=reject
- Receivers evaluate failed mail against the requested reject policy.
- New failures trigger investigation instead of automatic policy rollback.
- New senders need authentication and alignment before production.
- Blocklist and blacklist events are handled with source context.
Frequently asked questions
Yes. SPF authorizes the SMTP envelope source, DKIM signs the message, and DMARC checks whether either passing identity aligns with the visible From domain. Configure all three for each MegaMailServers-backed account before moving toward enforcement.
Use the exact include, hostname, or IP range supplied by your mailbox provider. Easily publishes include:spfc51.megamailservers.com for its service, but that is not a universal MegaMailServers include. Confirm your account settings rather than deriving SPF from an MX or PTR hostname.
That rDNS identifies MegaMailServers infrastructure, which can sit behind a hosted mailbox or reseller email service. Use the message headers, account records, and sending volume to map the source to the correct provider account before changing DNS.
Use p=reject only when the MegaMailServers-backed account and every other legitimate sender pass DMARC in live reports. Test forwarding, aliases, and mailing-list traffic before full enforcement. If the domain already uses quarantine or reject, keep that policy and fix the failing source.
SPF fails when the sending IP is not authorized for the evaluated MAIL FROM domain, including after forwarding. A provider MAIL FROM domain that differs from the visible From domain is an alignment issue; SPF can still pass. DMARC passes when DKIM passes with a signing domain that matches the From domain under the configured alignment mode.
Send a fresh message through the exact mailbox or SMTP route, inspect raw headers, confirm the evaluated SPF and DKIM domains, check DMARC alignment, then compare the result with aggregate reports after receivers process the new mail.
