Magnews SPF, DKIM and DMARC setup, step by step

Authenticate Magnews email by creating the visible sender domain, publishing its generated DKIM TXT record and selecting Activate certification. Magnews normally uses a technical return-path domain beneath magnews.net; to add branded SPF alignment, configure an exclusive technical sender domain, publish its issued MX and SPF TXT records, and activate that feature separately. Verify both the account settings and a newly delivered message. DKIM setup, technical sender setup.

Separate the sender domain from the technical sender

This guide covers email delivered through the Magnews platform. It does not configure a company's employee mail system or treat the DNS host as the sending service. Your DNS administrator publishes the records, while Magnews generates the configuration and enables the sending features.

Three identities need separate attention:

The default technical domain is managed by Magnews and is a subdomain of magnews.net. A passing SPF result for that domain is not SPF alignment with your own brand. Correctly configured branded DKIM can still provide the aligned pass needed for DMARC. Magnews DMARC explanation.

Before editing DNS, list every From domain, stream and Magnews account in use. Include relevant automated communications rather than assuming that a newsletter test covers them. Record who controls authoritative DNS and who can activate the domain in Magnews. Save existing DKIM selectors, SPF and DMARC policies, inbound MX and the complete record set at any proposed technical sender owner.

For separate employee mail sent by Microsoft 365, use the Microsoft 365 authentication guide. Those tenant records do not replace Magnews sender-domain certification.

Create the sender domain and obtain its DKIM record

The current dedicated setup guide uses Backstage → Deliverability → Sender domains. Choose Add sender domain, enter the domain and select Create sender domain. In its Information section, copy DNS Host Name and DKIM key, or use Download instructions for the DNS administrator. Current sender-domain procedure.

Some other help articles still use Settings → Brand Protection → Sender Domains. That is a documented navigation difference, not evidence that you should create a second sender-domain entry. Locate the equivalent domain list in your interface or ask Support if the controls are unclear. Alternate navigation in troubleshooting documentation.

Publish the issued material as a TXT record:

Type: TXT
Owner: the exact DNS Host Name shown for this sender domain
Value: the complete DKIM key value shown in its Information section

Do not substitute a static selector found on another website. The expected public key is associated with the domain's Magnews configuration; a valid DKIM record for an employee-mail service is not interchangeable with it.

When a DNS panel appends the zone name, translate the full owner into the appropriate relative host. For example, an issued SELECTOR._domainkey.news.example.com in the example.com zone would use SELECTOR._domainkey.news in such an editor. In a separately hosted news.example.com zone, it would use SELECTOR._domainkey. Confirm the saved full hostname instead of guessing from the label on the input box.

If _domainkey.news.example.com itself is delegated, the illustrated full owner SELECTOR._domainkey.news.example.com is relative SELECTOR in that zone. Preserve the delegation and publish with its actual authority, using the issued selector.

Preserve the complete public value and follow your DNS host's handling of long TXT data. Multiple quoted strings within one TXT resource record can be normal; separate competing key records at the same selector are not a safe workaround. Preserve other services' selectors, and stop if the requested owner conflicts with an existing record whose purpose is unknown. DKIM DNS contains public verification data, never the private signing key. DKIM selectors and keys.

Activate DKIM certification after publication

Return to the sender domain and select Activate certification. This verifies the TXT configuration and enables the certified sender domain. Publication alone is insufficient. Activation step.

Magnews explicitly distinguishes a record that is invalid from one that is correct but has certification deactivated. For the former, compare the published owner/value with the Information section. For the latter, complete activation instead of repeatedly replacing a good key. Certification troubleshooting.

Record when activation succeeded, but keep the rollout open until the intended branded signature passes on an actual message. An account status answers a configuration question; the receiver result answers whether that sending path used the configuration correctly.

Choose whether to customize the technical sender domain

In the sender domain's Summary tab, use Configure in the technical sender section. The documented choices are a subdomain of the sender domain, the sender domain itself as an advanced option, or continued use of the Magnews domain. The selected custom domain must be reserved exclusively for Magnews. The provider recommends the subdomain option; using the sender domain itself is advanced and recommended only when it is already a corporate subdomain. Technical-domain choices.

For example, with From news@example.com, an unused send.example.com isolates the bounce route from existing corporate mail. Do not choose example.com merely to get an exact domain match: changing its MX could interfere with employee mail. Similarly, a label that looks unused in the marketing team may already be used by a CRM, application or another sender. Check the authoritative zone and service inventory.

The practical decision is:

• Keep the default technical domain if your approved design relies on aligned DKIM and you do not need the custom SPF identity.
• Choose a dedicated subdomain when you want branded SPF alignment without taking over a shared mail domain.
• Consider the exact-domain advanced option only with a reviewed, exclusive domain design and a clear inbound/bounce-routing plan.

With From example.com and envelope domain send.example.com, SPF alignment is relaxed. Under aspf=s, the domains must match exactly. Strict DKIM alignment likewise requires the actual d= value to equal the From domain. Do not weaken an established policy just to avoid examining this design. DMARC alignment modes.

Publish the issued MX and SPF TXT, then activate

After choosing the technical-domain option, copy all the DNS instructions from Magnews. They contain an MX record for bounce reception and a TXT record for SPF. Select Save in the technical-domain dialog after choosing the configuration and copying its instructions. Saving this choice is separate from activation. Publish the records at the chosen technical sender owner, then use Activate technical sender in the Summary tab. Record types and separate activation.

Before publication or technical-sender activation, compare the complete issued routing set with the mail-routing owner’s separately approved design: exact technical owner, all numeric MX priorities and all destination hostnames. An issued packet is not permission to redirect mail. Query the exact MX owner at authoritative and recursive resolvers and require the entire approved set; any extra, missing or different target needs resolution. Preserve corporate mailbox routes and do not accept a merely nonempty MX response. Technical-domain routing requirements.

Do not invent a universal Magnews SPF include or MX destination. Use this worksheet to check what your account actually issues:

The MX priority belongs in the priority field, and its target is a hostname, not a URL or IP copied from a lookup. Preserve an absolute target as required by your DNS editor; check that the zone suffix was not appended to the destination. Confirm the complete MX set and priorities against the issued instructions.

If records already occupy the proposed technical name, do not resolve the conflict by blindly deleting them or merging unrelated senders into an owner that must be exclusive. Choose a clean subdomain or obtain a coordinated migration plan. A CNAME at the same owner conflicts with the ordinary MX/TXT combination. DNS alias restrictions.

SPF evaluates the actual MAIL FROM domain, not the visible From address. At each evaluated owner, keep one SPF policy and check the ten DNS-querying-term limit, including nested includes. Preserve legitimate authorizations on unrelated corporate domains. A parent record is not inherited automatically by the technical subdomain. SPF publication and evaluation.

If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.

Changing only a root SPF include will not switch the envelope identity, install the bounce MX or activate the technical sender. Likewise, successful DKIM certification does not prove this separately configured feature is active.

Keep DMARC policy and reporting deliberate

DMARC passes when at least one passing SPF or DKIM identifier aligns with the visible From domain. Both mechanisms should be healthy, but both do not have to be aligned for that DMARC decision. Magnews' own DMARC guide describes branded DKIM and optional technical-domain customization separately. Provider DMARC guidance.

Retain any established policy and reporting settings. Do not downgrade p=reject or p=quarantine because a new stream is not yet certified. Fix the new route before relying on it for production sending.

Where no policy exists and a monitored introduction is appropriate, the following is an example, not an instruction to replace an existing record:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use the actual From domain and a reporting address you control or have approved. Check applicable parent policy for a subdomain sender. Publish only one DMARC policy at a given owner. p=none requests no quarantine/reject treatment for DMARC failure; receiving providers retain their own filtering decisions. DMARC policy behavior.

For the approved first policy at From example.com, full TXT owner _dmarc.example.com maps to _dmarc in that zone. For From news.example.com, full owner _dmarc.news.example.com maps to _dmarc.news in the parent example.com zone or _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve any existing direct or inherited policy; this mapping does not authorize a child monitoring override.

Aggregate reports can expose other legitimate senders that need attention before enforcement. Verify external reporting authorization when a third-party rua destination requires it, and ensure reports reach the correct collection service. Aggregate reporting rules. EmailAuth can help organize the sender/alignment inventory, but a report review does not replace Magnews activation or a route-specific test.

Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.

Validate public DNS and a delivered message

Use actual account-issued owners in place of every placeholder below. These are illustrative, read-only commands; no customer DNS was queried in preparing this guide.

dig +short NS example.com
dig +noall +answer SELECTOR_FROM_MAGNEWS._domainkey.example.com TXT
dig +noall +answer send.example.com MX
dig +noall +answer send.example.com TXT
dig +noall +answer _dmarc.example.com TXT

For DKIM, check the full key record at the issued owner. For a custom technical domain, compare the entire MX response, including priorities and target hostnames, plus the complete SPF TXT policy with the current instructions. Query the authoritative DNS service if recursive caches disagree, then recheck after relevant TTLs. A DNS response containing a key does not prove signing, and an SPF TXT lookup does not evaluate the actual sending IP.

After DKIM certification, and technical-sender activation if you configured a custom domain, an authorized operator should send through the real Magnews communication route to a controlled mailbox. Inspect the raw source and trusted receiver-added Authentication-Results, rather than an edited forward or only the inbox's summary label. Authentication-Results trust and fields.

Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.

Diagnose SPF at the actual smtp.mailfrom independently, even when aligned DKIM supplies DMARC pass. fail or softfail calls for checking whether the connecting sender is authorized for that envelope route; temperror indicates transient evaluation trouble such as a DNS timeout; permerror calls for checking malformed syntax, duplicate policies and the evaluated DNS-term budget. A passing but unaligned SPF identity is a separate condition. SPF result meanings.

Record and require:

1. The expected From domain and message stream.
2. A passing DKIM signature for the intended branded header.d, with its actual selector and alignment to From under the effective adkim mode. A provider-domain signature or SPF-only DMARC pass cannot substitute for this branded-DKIM acceptance check.
3. SPF pass for the real smtp.mailfrom. If a custom technical domain was activated, the envelope must use that intended identity.
4. DMARC pass for header.from, with the expected relaxed or strict alignment.
5. Investigation of any actual SPF fail, softfail, none, neutral, permerror or temperror, even when DKIM makes DMARC pass.
6. Correct reply reception and bounce processing for the approved design.

For the default Magnews technical route, an unaligned SPF pass can be expected; it is not the same as an SPF error. For the custom route, continued use of an old provider envelope domain means the new feature's acceptance is not complete. Repeat the check for each distinct sender domain and independently configured stream.

Troubleshoot Magnews authentication warnings

Magnews documents these sender-domain warnings and separately checks the availability of an MX record and monitored reply address. Official troubleshooting reference.

Its Microsoft requirements page identifies authentication rejection 550; 5.7.515 and explains that related failures appear as Soft Block Bounce in Magnews. Preserve the full response and consult Bounce Analysis; do not automatically classify the recipient address as nonexistent because the send was blocked. Magnews Microsoft troubleshooting.

Documentation and verification limits

No customer account, DNS records or sending configuration was changed, and no test message was sent. Generated values, activation states, live DNS and delivered-message results still require implementation verification.