Mynewsdesk SPF, DKIM and DMARC setup, step by step

To authenticate Mynewsdesk newsroom emails with your company domain, open Email settings, choose the DNS-based sender-address change, enter your intended sender, and publish the three CNAME records issued by your account. Return to Verify DNS records, then check a newly delivered distribution email for an aligned branded DKIM pass and a trusted DMARC pass. Do not add a generic SendGrid include to your root SPF record.

This guide covers the Custom From Address version introduced in June 2021, used for press releases, news and other material distributed to Mynewsdesk lists. It does not configure a newsroom website domain, an independently managed SendGrid account, or an old sender setup by automatically resetting it. The official Mynewsdesk instructions are the authority for the account workflow.

June 2021 is the feature-version date, not a claimed update date for the documentation. No customer account, DNS change or sending test was performed for this guide.

On this page

• Before changing the sender
• Get the three account records
• Publish the CNAMEs safely
• Understand what changes for SPF
• Preserve the domain DMARC policy
• Verify DNS and a delivered message
• Troubleshoot the failing layer
• Frequently asked questions

Before changing the sender

Have these ready:

• A Mynewsdesk newsroom account with access to Email settings and the sender-address controls. The public procedure does not establish a universal plan or named role entitlement. If the controls are absent, have your account administrator or Mynewsdesk confirm access.
• An approved company From address, such as press@example.com. Use a domain your organization controls, not a public mailbox-provider domain whose DNS you cannot edit.
• The administrator of the authoritative DNS zone. This may be different from the registrar, website host or everyday mailbox provider.
• A copy of existing DNS records and the applicable DMARC policy, including any policy inherited from an ancestor domain.
• A controlled recipient mailbox whose administrator can identify trustworthy authentication results.

Record the existing sender before changing it. A From-address change affects the identity recipients see; changing Reply-To alone is not domain authentication. If an older custom sender already works, do not use Reset e-mail settings merely to follow this tutorial. Mynewsdesk documents that reset in its pre-June-2021 migration guidance. Plan any migration separately, including its effect on active distributions and existing records.

Get the three account records

Follow the current Custom From Address procedure and screenshots:

1. Open the settings gear, then Email settings. On the General tab, find Change sender address and click Select. The accompanying text also calls this choice Change sender with DNS.
2. Enter the email address you want Mynewsdesk distributions to use. Check its domain and spelling, then click Next.
3. On Insert records & verify, capture every Type, Name and Target. Copy DNS info provides the record instructions for your DNS administrator.
4. Publish the three issued CNAMEs at their exact owners. Two owners are DKIM selectors beneath _domainkey; the other is the return-path authentication record.
5. Return to the account and click Verify DNS records once the published records are available. Resolve any validation errors rather than assuming a saved DNS form completed the setup.

The documentation screenshot contains tenant-specific SendGrid targets and region-like selector labels. They are examples, not reusable settings. Your account is the source of the actual names and targets. Do not substitute a selector from another newsroom, shorten a target, or generate an unrelated DKIM key yourself.

The return-path CNAME delegates provider-managed SPF-related DNS; the selector CNAMEs lead to provider-managed public DKIM keys. This is consistent with SendGrid's domain-authentication architecture, but its standalone account options and record counts are not additional Mynewsdesk steps. Install the Mynewsdesk-issued set, not a packet assembled from a general SendGrid tutorial.

Publish the CNAMEs safely

Translate each full owner into the correct zone

DNS panels differ: some expect a complete hostname; others append the current zone to the name you enter. These are owner-mapping examples only, not Mynewsdesk selectors or targets:

Issued full owner: SELECTOR._domainkey.example.com
Zone being edited: example.com
Relative name: SELECTOR._domainkey
Issued full owner: SELECTOR._domainkey.news.example.com
Parent zone: example.com
Relative name in parent zone: SELECTOR._domainkey.news
If news.example.com is separately delegated:
Zone being edited: news.example.com
Relative name in that zone: SELECTOR._domainkey

Replace SELECTOR with the account-issued selector. Map the return-path owner using the same full-name rule. A doubled suffix such as .example.com.example.com creates a different record, even if the DNS panel accepts it.

Check for delegation before editing. If _domainkey.example.com is delegated to another DNS service, the selector belongs in that service's authoritative zone, often with only the selector as the relative name. Do not delete the delegation or create a shadow record in the parent zone. Existing selectors may serve other applications or key rotation; preserve them unless their owners approve a migration.

Keep the issued CNAME visible

At each issued CNAME owner, inspect existing data before saving. A CNAME cannot share its owner with ordinary TXT, A, AAAA or MX data, or with a second different CNAME. If a selector or return-path name is already in use, resolve the collision with its owner and Mynewsdesk. Do not overwrite another sender's key. See RFC 1034 section 3.6.2.

For Cloudflare, use DNS only, not the HTTP proxy, for authentication CNAMEs. Also check flattening: a DNS-only label alone does not prove that a literal CNAME is being returned. Turn off per-record flattening where applicable. If zone-wide flattening, apex handling or same-zone-target behavior hides the CNAME, have the DNS administrator resolve the specific configuration without blindly changing the whole zone. Cloudflare documents proxy status and flattening behavior, including cases where per-record settings do not control the outcome.

Use the exact target as a hostname, not a URL: no https://, path or copied quotation marks. Do not replace the CNAME with the TXT value it currently resolves to; that can bypass provider-managed key changes. This setup does not require changing your receiving MX, parent nameservers, DNSSEC or mailbox credentials.

Understand what changes for SPF

There is no universal apex SPF record to paste for this Mynewsdesk workflow. Its issued return-path CNAME is different from authorizing a service in the SPF TXT record at example.com.

SPF evaluates the actual SMTP MAIL FROM domain, commonly reflected in the received Return-Path, rather than automatically evaluating the visible From address. Inspect the receiver's smtp.mailfrom result to discover the identity actually used. Editing root SPF cannot repair an unrelated envelope domain. RFC 7208 defines that identity and SPF evaluation.

Preserve your existing SPF policy and legitimate mailbox, CRM and other senders. At any owner where SPF is evaluated, there must be only one v=spf1 TXT policy. If a separately justified change is needed, reconcile it into that single policy with its administrator; do not append a second policy or casually change its -all or ~all qualifier. Those qualifiers express authorization results, not guaranteed delivery or rejection.

The SPF limit is 10 evaluated DNS-dependent terms, including nested lookups reached through mechanisms such as include and modifiers such as redirect. It is not simply ten visible includes. Keep this budget in view when troubleshooting a real SPF permerror, including a provider-managed policy reached through the return-path CNAME.

For alignment, a hypothetical MAIL FROM domain bounce.example.com and visible From domain example.com can align under relaxed SPF alignment because they share an Organizational Domain. They do not match under strict aspf=s. This is an illustration, not a promised Mynewsdesk envelope name. DKIM must be checked separately against the actual signing domain.

Preserve the domain DMARC policy

Look up _dmarc for the intended From domain and determine the effective policy through current DMARC policy discovery, including applicable ancestor policy. A missing record at a child domain alone does not mean the domain has no policy. Preserve existing p, sp, alignment settings and authorized report destinations. A SERVFAIL, timeout or broken delegation is an error to investigate, not proof that a record is absent. RFC 9989 defines alignment and policy discovery.

Only if there is no applicable direct or inherited policy, and the domain owner approves a first monitoring policy with a plan to review results, this minimal example is appropriate for mail From example.com:

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

For From news.example.com, the full owner is _dmarc.news.example.com: enter _dmarc.news in the parent example.com zone, or _dmarc in a separately delegated news.example.com zone. Do not use this example to override an inherited enforcement policy. Publish one DMARC policy at the owner, not a second record alongside the existing one.

The minimal record has no rua, so it does not request aggregate reports. Add a reporting destination only after its owner and your organization approve the recipient, access and retention arrangements. Reports can disclose sending infrastructure and traffic patterns.

For reporting authorization, compare the Organizational Domain where the DMARC policy was found with the Organizational Domain of the report URI's host. If they differ, report-generating receivers must check DNS authorization; a destination within the same Organizational Domain is excepted, even if its hostname differs. The external recipient normally publishes authorization at POLICY-DOMAIN._report._dmarc.REPORT-DESTINATION-HOST with v=DMARC1. Obtain the exact instruction from the reporting service. This protocol check does not replace your organization's data-sharing approval. See RFC 9990 section 4 and its privacy considerations.

Verify DNS and a delivered message

Check publication, then verify in Mynewsdesk

These are read-only command templates. Replace every uppercase placeholder with an actual full name or DNS-server address; no results below are fabricated:

dig @AUTHORITATIVE_DNS_SERVER FULL_ISSUED_CNAME_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER FULL_ISSUED_CNAME_OWNER CNAME +noall +answer
dig @PUBLIC_RESOLVER ISSUED_DKIM_TARGET TXT +noall +answer
dig @PUBLIC_RESOLVER ACTUAL_MAIL_FROM_DOMAIN TXT +noall +answer
dig @PUBLIC_RESOLVER _dmarc.ACTUAL_FROM_DOMAIN TXT +noall +answer

Repeat the owner queries for all three records. The CNAME answer must name the exact issued target. Follow the DKIM target to its public key; SPF resolution follows the actual envelope domain and any relevant alias. Inspect full responses without +noall +answer if answers are missing, so you can distinguish negative answers from resolver failures. Authoritative and public answers may differ while old or negative responses remain cached.

Once the records match, use Verify DNS records in Mynewsdesk. Account acceptance is a useful checkpoint, not evidence that every outgoing message is correctly signed.

Test the native newsroom sending path

Send a fresh distribution message using the intended custom From to controlled recipients. Do not use a forwarded old message or a message sent from your everyday mailbox. If several newsroom identities or distribution routes matter, test each relevant configuration.

From the received original, retain these authentication facts:

• The actual visible From domain, not just the display name or Reply-To.
• The intended Mynewsdesk signature's d= signing domain and s= selector, taken from the same DKIM-Signature field.
• The trusted receiver's result for that signature: dkim=pass, with its signing domain aligned to the intended From.
• The trusted receiver's dmarc=pass for that From domain.
• The separate SPF result and actual smtp.mailfrom identity, including any errors or lack of alignment.

Use EmailAuth's guide to finding a DKIM selector to map the observed s= and d= to SELECTOR._domainkey.SIGNING-DOMAIN. Two published selectors do not mean that both signatures must appear in every message.

Under relaxed adkim=r, the signing and From domains must share an Organizational Domain; strict adkim=s requires an exact match. A generic DMARC pass supplied by SPF does not prove that the intended branded DKIM setup works. Likewise, a rewritten provider-owned From address is not success for your company From.

Trust only results your receiving infrastructure actually generated or verified. A matching authserv-id string or a header's position alone is not proof: injected headers can imitate them. If the mailbox cannot distinguish trusted results, use an administrator-verified receiving trace or another controlled receiving system. RFC 8601 explains this trust boundary.

Troubleshoot the failing layer

• DNS verification fails: compare all three account-issued rows with authoritative DNS. Check suffix duplication, wrong zone, delegated namespaces, CNAME conflicts, proxying, flattening and cached answers. Do not reset the sender as the first remedy.
• DNS verifies but branded DKIM is absent: confirm the selected sender and that the message came from native Mynewsdesk distribution. Give Mynewsdesk the account's verified domain, observed signing identity and redacted authentication evidence.
• DKIM fails: query the actual selector/signing-domain pair, not a guessed selector. Check the complete CNAME chain and key. If DNS is correct, investigate signing configuration or message modification by a relay.
• DKIM passes but DMARC fails: compare the passing signature's domain with the actual From under adkim. A valid provider-domain signature may be unaligned. Fix the sender identity or authentication path, not the enforcement policy.
• SPF fails while DMARC passes: investigate the actual MAIL FROM policy and sending IP independently. fail or softfail differs from a passing but unaligned SPF identity; temperror indicates a transient evaluation problem, while permerror can indicate duplicate policies, malformed syntax or an exceeded lookup budget.
• All authentication checks pass but mail goes to spam: review content, recipient consent, reputation and receiver filtering separately. Authentication is not an inbox-placement guarantee.