[ Sending-service guides ]
Authenticate email sent through Inwise: configuration and verification
Authenticate an inwise campaign domain while correcting the published SPF example safely and confirming the account’s current DKIM key.
By the EmailAuth research team · 4 min read
[ Key points ]
- Approve a tested campaign sender
- Reconcile records rather than copy examples
- Keep policy changes accountable
[ Takeaway ]
Authenticate an inwise campaign domain while correcting the published SPF example safely and confirming the account’s current DKIM key.
[ By role ]
What this means for you
Choose your role for practical next steps.
IT / Mail Admin
Reconcile records rather than copy examples
The public SPF example needs syntax correction and the current DKIM key needs confirmation.
Next steps
- Preserve the existing SPF policy.
- Obtain current signing details.
- Compare DNS answers with received identities.
CISO / SecOps
Keep policy changes accountable
A campaign setup should not silently change domain-wide protection.
Next steps
- Inventory other senders.
- Approve enforcement separately.
- Review retained message evidence with the mail team.
Founder / Non-technical
Approve a tested campaign sender
The selected campaign profile must use the identity that was actually verified.
Next steps
- Name the campaign owner.
- Retain the working profile.
- Approve rollout after a controlled send.
[ FAQs ]
Frequently asked questions
What is wrong with the published SPF example?
It lacks a space between the include domain and -all; those must be separate SPF terms.
Should I add a second SPF record for inwise?
No. Reconcile the approved mechanism into the existing policy at the applicable owner.
Can I publish the static DKIM key without checking?
Confirm that the current account still uses that selector and key before deployment.
Does the verification code prove DMARC passes?
No. It verifies mailbox access; receiver authentication requires a real message test.
Why can DNS be valid but the campaign use the wrong address?
The selected sender profile or campaign setting may still point to an older identity.
Does this establish a custom Return-Path feature?
No. The retrieved campaign setup does not establish that capability or a live campaign’s envelope domain.
Should I copy -all when merging the include?
Retain the domain’s approved overall policy unless a separate review authorizes changing it.
What remains open before acceptance?
Current key confirmation, live DNS answers, actual envelope and signing identities, receiver results and human SME approval.
[ Sources ]
Sources
- Domains Authentication
Sections Step 1: Domain authentication · Step 2: SPF record authenticate · Step 3: DKIM record authenticate · Step 4: Update sender’s email address
- RFC 7208 SPF
Sections §4.6.4 · §3.2
- RFC 6376 DKIM
Sections §3.5 · §6
- RFC 9989 DMARC
Sections Identifier Alignment
[ Glossary ]
Glossary
- SPF include
- An SPF mechanism that evaluates another domain’s policy as part of sender authorization.
- Terminal policy
- The final SPF mechanism that determines treatment of sending hosts not otherwise matched.
- Sender profile
- Campaign settings that select the outbound identity used by a message.
- DKIM public key
- The DNS-published verification material corresponding to the sender’s private signing key.
- DMARC alignment
- The required relationship between the visible From domain and a passing SPF or DKIM domain.
Enterprise provenance
Why top financial institutions and governments retired their email security dashboards.
Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.
EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.
SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption