Smartmessages SPF, DKIM and DMARC setup, step by step

To authenticate a custom From domain on hosted Smartmessages.net, publish the provider's sm2 2048-bit DKIM public key, reconcile include:smartmessages.net with the appropriate single SPF policy, and register the domain under Settings → Domain auth. Use Recheck all after DNS changes. Then verify that an actual Smartmessages message carries a passing signature aligned with your intended From domain.

Smartmessages already signs mail, but its official DKIM instructions say that without your custom-domain configuration it uses d=mail.smartmessages.net. A passing signature from that provider domain does not authenticate an unrelated company From domain for DMARC.

This guide covers the hosted .net service operated by Synchromedia. It does not cover Smartmessages+ on your own servers, the separate .eu sm4 deployment, or obsolete DomainKeys setup. See the current product overview.

The currently linked User Guide has April 2023 PDF metadata. Those are source dates, not claims of recent product changes or completed customer testing.

On this page

• Confirm the account and exact From domain
• Publish the sm2 DKIM record
• Reconcile the SPF policy
• Register and verify the domain
• Preserve DMARC and understand alignment
• Test a real Smartmessages message
• Troubleshoot the failed stage
• Frequently asked questions
• Sources and verification limits

Confirm the account and exact From domain

You need access to the hosted account's domain-authentication settings and permission to edit the relevant authoritative DNS zone. The retrieved public instructions do not name a narrower administrator role or paid-plan requirement. Do not assume account access also grants DNS access.

Use the domain after @ in the address recipients should see:

• newsletter@example.com requires example.com.
• newsletter@news.example.com requires news.example.com.
• www.example.com is not the right domain merely because it is your website address.
• Each different From domain must be configured and registered separately.

These distinctions are explicit in the Smartmessages User Guide, printed page 9. You cannot publish authentication records for a public mailbox domain you do not control.

Identify the authoritative DNS host, which may differ from your registrar or website provider. Save the existing SPF, DMARC, DKIM and relevant NS/CNAME records before editing. This setup does not require moving your nameservers, changing receiving MX, deleting other services' selectors or sharing DNS credentials with anyone.

Publish the sm2 DKIM record

The complete provider-published public key

The official wiki's “DKIM and DomainKeys” entry publishes this record for the hosted Smartmessages.net sm2 selector. It is a shared provider public key, not a tenant-specific key generated by an Add Domain wizard. The provider retains the private signing key; you do not create, request or publish a private key for this hosted procedure.

For the example From domain example.com, the record is:

Type: TXT
Full owner: sm2._domainkey.example.com
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqKmFo0mnBMoJeJYbVvwSOflmISd5jkKAO0xowlJUEE+PYHXt7hgHFqc7SiFj2sKN2R8xI4ifFgz/0zuVYUe9gGT4cpuVy1Gu746K+R5tSd7EmnXgZe2PFogu/b+YABjQaR9GpF7VuZCXXGyueCL75Pabx3QzRr8ZtIFIUfqNyhH2WlaodFQqfxiPbxmWMlNhs8/mXDtijlt7b56hrWHTq+Ash/ut4OB53cZF8PBxNt8eCJXrdV0aqqefFJzmFDVSFTykWZ63tL7VKYvrVEvKS2BwjRI0pqrfpnLFeQbNV6waUEPAFZOHa/FQr01jSh5BJtHPQHp8COBzYoTqjeBKaQIDAQAB

Replace the example domain, not the key or selector, for this documented route. Recheck the official entry when implementing, especially if Smartmessages has subsequently announced a key change. Do not substitute a key from an old screenshot, a different service or the .eu section.

Put the owner in the correct zone

DNS panels handle relative names differently:

• In the example.com zone, sm2._domainkey commonly creates sm2._domainkey.example.com.
• For From domain news.example.com managed in the parent zone, the relative name is commonly sm2._domainkey.news.
• In a separately delegated news.example.com zone, use the relative name sm2._domainkey there.
• If _domainkey is already delegated, establish who controls the exact selector name before editing. Preserve the delegation and unrelated selectors.

Check the resulting full name. A panel that appends the zone can accidentally create sm2._domainkey.example.com.example.com if you enter a full name where it expects a relative name.

For the complete owner sm2._domainkey.news.example.com, a separately delegated _domainkey.news.example.com zone uses relative sm2. A full-name field takes that complete owner. Preserve the existing NS delegation and publish through its actual operator, not an inactive parent-zone copy. DNS zone boundaries.

The documented record is TXT, not CNAME. If the exact owner already has a CNAME, do not add conflicting TXT or remove the alias blindly. Determine which existing service uses it and resolve the collision with the domain administrator. RFC 1034, section 3.6.2 defines this CNAME ownership constraint.

Keep the key intact

Some DNS systems split a long TXT value into quoted strings of at most 255 octets. That is acceptable when they are strings within one TXT resource record, joined without added spaces inside the key. Two separate TXT records containing half a key are not equivalent. The complete tags and base64 data must survive publication. See RFC 6376, section 3.6.2.2.

Follow your DNS host's value-entry format. The wiki's suggestion to escape semicolons is format-dependent; do not insert literal backslashes into a managed TXT value unless that DNS interface requires them.

Do not add the wiki's legacy _domainkey policy o=~. That belongs to obsolete DomainKeys, not the DKIM sm2 setup. Nor should a new setup use the historical sm 384-bit key or select sm1 merely to avoid proper TXT splitting. RFC 8301 requires RSA keys of at least 1024 bits and recommends at least 2048; sm2 is the provider's documented 2048-bit choice.

Reconcile the SPF policy

The Smartmessages SPF entry publishes this authorization mechanism:

include:smartmessages.net

It is not a complete SPF record on its own. If the domain already has an SPF TXT policy, have its administrator merge this mechanism into that single policy while retaining legitimate senders and the approved qualifier. Put it where it will be evaluated, normally before the terminal all mechanism. Do not add a second v=spf1 record or paste a new policy over an existing one.

For a domain with no SPF policy, first inventory all senders and establish the complete policy with the owner. The wiki's examples include a, mx and permissive qualifiers. These are not mandatory Smartmessages settings: a and mx authorize additional addresses, and a receiving mail server is not automatically an intended sending server. Prefer the provider's include rather than manually copying its example IP address.

SPF has a limit of 10 evaluated DNS-dependent terms, including nested mechanisms reached through includes and redirects. It is not simply a limit of 10 written includes. Also, any all mechanism causes redirect= to be ignored. An existing redirect policy therefore needs a deliberate design, not a routine append operation. RFC 7208 defines these rules.

Root SPF is not proof of SPF alignment

SPF evaluates the actual SMTP MAIL FROM domain, commonly reflected in the delivered Return-Path, rather than automatically checking the visible From domain. The public Smartmessages instructions do not establish a configurable custom MAIL FROM facility or one universal envelope domain for every message.

Follow the provider's documented SPF requirement, but inspect the real envelope before attributing a failure or claiming DMARC alignment. A passing SPF result for a provider-owned envelope can remain unaligned with your brand. Publishing an include at example.com cannot change an envelope identity the sender did not use.

The old wiki advice that DMARC requires ~all instead of -all is not a protocol requirement. Preserve the owner's intended qualifier; neither one alone determines what a recipient delivers. Authentication, alignment and receiver policy are separate decisions.

Register and verify the domain

After publishing DNS:

1. Open Settings → Domain auth in Smartmessages.net.
2. Enter the exact domain used in the From address in Add domain.
3. Select + Add.
4. Inspect the Domain authentication report for that domain, including SPF, DKIM and Key size.
5. After correcting DNS, select Recheck all and wait for the platform's resolver to observe the new records.

The official User Guide, printed page 9, shows these labels and a 2048-bit key result. Older wiki instructions call the location the account's settings tab and “authenticated domains”; do not mistake that naming difference for a second activation workflow.

The guide warns that domains marked as failing will not use authentication. Do not ignore a red result because a public checker looks green. Confirm that Smartmessages itself sees the intended domain and complete key before using it for production mail.

The wiki says Smartmessages automatically chooses the appropriate registered From domain and, when multiple supported keys are configured, uses the longest one. It also explicitly requires verification on the settings page. DNS publication and domain registration are therefore both required; there is no additional documented “start signing” toggle to invent.

Allow for DNS TTLs and resolver caching, including cached negative answers. A newly added record is not guaranteed to become visible instantly. Avoid repeatedly rewriting a correct record while waiting for caches to expire.

Preserve DMARC and understand alignment

DMARC passes when at least one authenticated identifier aligns with the visible From domain. For DKIM, compare the passing signature's d= domain with From. For SPF, compare the passing MAIL FROM domain. Relaxed alignment requires the same Organizational Domain; strict alignment requires identical domains. See RFC 9989, section 4.4.

For example, d=news.example.com and From newsletter@example.com can relaxed-align but are not strictly equal. d=mail.smartmessages.net and From newsletter@example.com are not aligned under either mode. Register the exact intended From domain rather than relying on a related hostname or on the service's fallback signature.

Keep any applicable direct or inherited DMARC policy, alignment settings and authorized reporting destinations. Do not replace an existing policy with p=none to make setup easier, add a duplicate DMARC record, or weaken enforcement to hide an unsigned route. If there is no applicable policy, the domain owner should choose an initial policy and monitoring plan after inventorying legitimate senders. RFC 9989, section 4.10.1 governs policy discovery.

A conditional first-policy example

Only when no direct or inherited DMARC policy applies, the owner has inventoried the domain's senders, and the owner has approved an initial monitoring policy, this is a first-record baseline for the example From domain example.com:

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

Map that owner to the actual From domain and authoritative zone:

• For From domain example.com in its own zone, the relative name is commonly _dmarc.
• For From domain news.example.com managed in the parent example.com zone, the full owner is _dmarc.news.example.com and the relative name is commonly _dmarc.news.
• For a separately delegated news.example.com zone, that same full owner is commonly entered as _dmarc in the child zone.

Check the DNS host's suffix handling and publish one DMARC policy record at the selected owner. An empty direct lookup is not enough to justify this example: first check inherited policy. Never use this child-domain baseline to bypass an applicable parent policy or replace existing enforcement.

The baseline does not request aggregate reports by itself. If monitoring includes reports, append a rua tag naming an actual, owner-approved reporting destination to that same policy, after arranging receipt and any required authorization. Do not copy another organization's reporting address.

If aggregate reports go to a destination in a different Organizational Domain from the domain where the DMARC policy was discovered, the report-generating receiver must check external-reporting DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not make it external. RFC 9990, section 4 defines the check. DNS authorization does not replace the owner's separate decision to share report data with that recipient.

Test a real Smartmessages message

Use a controlled recipient you are authorized to email. Send through the actual hosted Smartmessages workflow with the intended From address, not through an employee mailbox or a forwarded copy. Preserve the original received message.

Acceptance for this new branded DKIM setup requires all of the following:

• The visible From address is the intended brand address, not a provider rewrite.
• The intended Smartmessages custom-domain signature passes DKIM and its d= aligns with that From under the effective DMARC alignment mode.
• The trusted receiver reports dmarc=pass.
• The actual MAIL FROM and its SPF result are understood; any SPF failure, temporary error or permanent error is investigated separately.

A DMARC pass obtained only through SPF does not prove that the new DKIM configuration works. Likewise, a passing fallback signature from mail.smartmessages.net is not acceptance for your brand.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For a signature using s=sm2 and d=example.com, these are illustrative, read-only checks. Replace the example domain with the actual d= from that same signature:

dig TXT sm2._domainkey.example.com +noall +answer
dig CNAME sm2._domainkey.example.com +noall +answer

The intended direct-TXT route should expose the complete public key; an unexpected CNAME needs investigation, not automatic deletion. A public DNS answer cannot show whether the sender used the matching private key or whether content changed afterward. EmailAuth's guide to finding the DKIM selector in a message explains how to keep each s=/d= pair and trusted result together.

Troubleshoot the failed stage

Smartmessages shows a red DKIM check

Confirm the registered domain matches the intended From domain. Check the authoritative zone, duplicated DNS suffixes, the exact sm2._domainkey owner, key truncation and accidental multiple TXT records. Compare the complete published key with the current official wiki, then use Recheck all after caching allows the change to be seen.

DNS looks right but the message uses the provider domain

Check domain registration and the platform's own result, not just public DNS. Confirm the actual message was sent through the expected account and From identity. The provider documents fallback signing when your custom key is not configured; do not count that fallback as successful custom-domain activation.

DKIM passes but DMARC fails

Compare the passing d= with the visible From and inspect strict versus relaxed alignment. Ensure you did not configure example.com while sending from a different, unregistered domain. Treat multiple signatures individually; a pass on the wrong signature is not proof that the intended one works.

SPF fails while DKIM passes

Identify the evaluated MAIL FROM domain and actual outbound source. Fail may indicate missing authorization or the wrong route; temperror points to a temporary lookup problem; permerror can result from duplicate SPF policies, invalid syntax or an exceeded lookup budget. Aligned DKIM may still produce a DMARC pass, but that does not repair the SPF fault.

An old selector is still present

Inventory which selectors live messages use and which delayed or archived messages may still need them. Do not delete another service's selector, a working shared dependency or an old key merely because sm2 has been added. Plan migration and retirement with the sender and DNS owners; key changes must be followed by platform rechecking and message validation.

Sources and verification limits

Primary references are the Smartmessages wiki, the official User Guide, the guide-download page and the current product description. The key above was checked against the full current wiki body, not reconstructed from a screenshot.

No customer sign-in, DNS change, platform activation, campaign send or received-message test was performed for this guide. The final evidence must come from your authorized account, DNS and actual sending route.