To authenticate native Element451 Campaigns email, an administrator opens Settings → General → Sender Domain Authentication, adds the intended domain and publishes the records shown in its Data column. Element451 and its integrated sending partner, SendGrid, supply the SPF/DKIM configuration. Your DNS administrator publishes the issued CNAMEs and an approved DMARC TXT policy at the exact domain Element451 checks. A green check in Status confirms the platform's configuration check; a controlled native message must still prove aligned DKIM and DMARC success.
Do not replace this workflow with a standalone SendGrid account, a generic SPF include or a guessed selector. The records must belong to the domain and institution in the actual Element451 account.
1. Scope, permission and preparation
This guide covers the native Campaigns email channel. It does not configure a personal mailbox, SMS, push notifications or an unrelated product with a similar name. Element451's authentication overview identifies SendGrid as its bulk-email partner and explicitly requires Element451 Administrator permission for the authentication setting.
Before starting, establish:
- The approved sender address and exact domain to place on the authentication card.
- An authorized Element451 administrator and the actual authoritative DNS operator.
- Existing selectors, DNS delegations, SPF policies and direct or inherited DMARC protection.
- An approved reply mailbox and the campaign routes or personalized versions that will use the sender.
- A saved before-state, a change owner and a controlled test audience.
DNS authority may be with a different company from the registrar. A campaign user's access does not grant permission to edit domain DNS or change an institution-wide default sender. If the administrator setting is absent, resolve permissions or account applicability with the account owner rather than creating another sending service or changing credentials.
The domain, DNS records and account settings are three connected but separate objects. Adding a domain card does not publish records; publishing records does not prove signing; receiving a message does not prove that the intended signature aligned.
2. Add the domain and obtain its issued records
Use the native path in General Settings:
- Open the profile menu in the top-right navigation and choose Settings → General.
- Locate Sender Domain Authentication.
- Select Add Sender Domain.
- Enter the exact approved domain and click Add.
- Find its new entry and copy the configuration from Data.
Element451 distinguishes the columns explicitly: Data contains setup instructions; Status is the live configuration indicator. The presence of a populated Data column is not success.
The optional Send Instructions control emails the requirements to another person. Use it only for an authorized recipient and approved purpose. Otherwise, provide the public DNS packet to your responsible administrator through the institution's approved channel. Do not send passwords, account tokens or private DKIM keys.
| Item | Documented type or source | Required action |
|---|---|---|
| SPF/DKIM setup | CNAME records issued through Element451's integrated sending configuration | Copy every account-issued type, owner and target; do not substitute another SendGrid account's values |
| DMARC | TXT policy at the exact domain on the authentication card | Preserve effective existing protection and have the domain owner approve any necessary exact-domain policy |
| Configuration result | Green check in Status | Confirm the intended domain, not merely a different authenticated domain in the account |
| Sending identity | Sender Email Addresses and campaign settings | Select an approved address on the authenticated domain and check defaults and versions |
The overview mentions “four separate DNS record types,” but its operative SPF/DKIM instructions describe CNAMEs and its DMARC procedure describes TXT. Do not invent extra record types or a fixed count from that wording. Use the complete current Data packet. If it asks for a materially different route, stop and resolve the discrepancy with Element451 before publishing.
3. Publish the CNAMEs without disturbing other mail
At the authoritative DNS host, create the issued CNAME records exactly as requested. Save the complete owner and target for each row in your change record. Use the host's ordinary TTL default unless your approved instructions specify otherwise.
The protocol being configured and the DNS record type are not interchangeable. A CNAME used in the provider's SPF arrangement is still entered as CNAME, not converted to an SPF TXT value at the same owner. Likewise, a DKIM CNAME points toward provider-managed public verification material; it is not a request for you to generate keys.
Map the full owner to the zone editor
These are illustrative placeholders, not Element451-issued names. Replace SELECTOR, ENVELOPE and example.edu with the actual packet's labels and domain.
| Full DNS owner | Zone being edited | Relative owner if the editor appends that zone |
|---|---|---|
SELECTOR._domainkey.example.edu |
example.edu |
SELECTOR._domainkey |
ENVELOPE.example.edu |
example.edu |
ENVELOPE |
SELECTOR._domainkey.send.example.edu |
Parent example.edu |
SELECTOR._domainkey.send |
ENVELOPE.send.example.edu |
Parent example.edu |
ENVELOPE.send |
SELECTOR._domainkey.send.example.edu |
Delegated send.example.edu |
SELECTOR._domainkey |
ENVELOPE.send.example.edu |
Delegated send.example.edu |
ENVELOPE |
SELECTOR._domainkey.send.example.edu |
Separately delegated _domainkey.send.example.edu |
SELECTOR |
If the editor requires a fully qualified name, use the full owner. Inspect the saved result to catch a doubled zone suffix. Preserve existing NS delegations; the non-DKIM records do not belong in a _domainkey zone just because the selector does.
At a CNAME owner, do not add a conflicting A, AAAA, MX, TXT or second CNAME. If an issued name is occupied, identify its owner and dependencies before proposing a resolution. Do not delete a working record or delegation simply to clear validation.
Keep authentication aliases visible
Where the DNS host has a web proxy, leave these records DNS only, not HTTP-proxied. Cloudflare documents that distinction in its proxy-status guide.
Ensure CNAME flattening does not conceal the issued aliases. Turn the applicable per-record Flatten control off where available, and ensure whole-zone settings do not suppress these records' CNAME answers. Coordinate shared-setting changes rather than switching unrelated records globally. Mandatory apex or same-zone behavior can differ from ordinary per-record settings; if the required answer cannot be preserved, stop and arrange a supported configuration. Do not invent a switch or move nameservers. See Cloudflare's CNAME-flattening setup documentation.
Element451 links to SendGrid's authentication troubleshooting, which explains doubled DNS suffixes and record conflicts. Use those diagnostics, not its standalone account controls, example selectors or alternative MX/TXT setup. Changing the integrated service's security mode is not part of this guide.
4. Understand SPF without inventing an apex include
Element451 supplies the native SPF/DKIM configuration through the account packet. Do not append include:sendgrid.net to your apex merely because SendGrid is the backend, and do not replace the SPF used by staff mail or other services.
SPF evaluates the actual SMTP MAIL FROM identity, or HELO in the relevant cases. That is not automatically the visible From domain. The provider's issued envelope-domain CNAME and a staff-mail apex policy can therefore serve different identities.
If a separate approved policy change is genuinely needed at an owner you control, preserve one v=spf1 TXT policy, existing legitimate authorizations and their qualifiers. Check the ten evaluated DNS-dependent term limit across nested mechanisms, not just the number of top-level includes. A policy containing all ignores redirect. These are RFC 7208 rules, not permission to alter unrelated records.
Later, record the actual envelope identity and SPF result from a native campaign. Do not infer strict SPF alignment from a branded subdomain or a green account status.
5. Satisfy Element451's exact-domain DMARC check safely
Element451's authentication overview imposes a product-specific check: it looks for DMARC at the exact domain on the Sender Domain Authentication card. If the card is send.example.edu, it expects _dmarc.send.example.edu. A root policy alone does not pass that check, even when receiving mail systems would apply it to the child domain.
This is not a reason to weaken an inherited policy. The DNS and security owners must first determine the policy that currently applies, including any parent sp behavior, alignment requirements and approved reports. Preserve an existing valid exact-domain record. If a new child record is needed to satisfy the product check, have the owner approve an explicit policy that maintains the effective protection and reporting decisions.
For example, a parent with p=none; sp=reject can apply rejection to an otherwise unconfigured child. Blindly copying only the parent's p=none into that child would weaken protection. The new child policy must reflect the approved effective behavior, not a literal copy of one tag. Leave the root record in place and preserve required adkim/aspf modes; do not relax an established strict mode just because the provider's overview recommends relaxed alignment.
| Domain on the card | Full DMARC TXT owner | Relative input in the actual zone |
|---|---|---|
example.edu |
_dmarc.example.edu |
_dmarc in example.edu |
send.example.edu, hosted in the parent zone |
_dmarc.send.example.edu |
_dmarc.send in example.edu |
Separately delegated send.example.edu |
_dmarc.send.example.edu |
_dmarc in send.example.edu |
Use the full owner if your editor expects it. Do not put DMARC in a separately delegated _domainkey zone or add duplicate policies at one owner.
Conditional first policy, not a replacement
Only if no applicable direct or inherited policy exists, the owner approves first-time monitoring and there is an appropriate monitoring plan, a minimal TXT policy can be:
v=DMARC1; p=none
Element451 permits more stringent policies, so this is not a requirement to use none. It requests no enforcement and does not produce aggregate reports without an approved report destination. Do not copy the overview's sample reporting addresses or obsolete percentage-rollout examples.
If the owner chooses an actual rua=mailto: destination, approve report sharing separately. A destination in a different Organizational Domain from the domain where the applicable DMARC policy is discovered requires the report-generating receiver to check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone is not external. See RFC 9990, section 4. Creating a new exact-domain policy can change the policy domain used in that authorization check, so reassess it rather than assuming an older authorization still covers the new policy owner. DNS authorization does not replace the institution's privacy decision.
Current policy evaluation follows RFC 9989. If the account check and an approved policy appear incompatible, preserve protection and hold release while the account and security owners resolve it. Element451 says its Support team does not configure the institution's DMARC policy; that decision belongs with the DNS/IT owner.
6. Check Status and select the intended sender
After publication, return to Sender Domain Authentication and check Status for the intended domain. The documented success indicator is a green check mark. The reviewed procedure does not establish another DKIM enable toggle or an additional activation button; do not invent one.
If status does not become green, compare the actual authoritative answers with the current Data packet, then allow for DNS caching. The backend troubleshooting guide discusses propagation delays, but it is not a guaranteed Element451 completion deadline. Do not repeatedly replace records or weaken DMARC while waiting.
Read-only queries can help. Replace every uppercase placeholder with the complete issued owner or approved policy owner:
dig CNAME ISSUED_CNAME_FULL_OWNER
dig TXT ISSUED_DKIM_FULL_OWNER
dig TXT EXACT_CARD_DMARC_FULL_OWNER
The CNAME answer should preserve the intended alias and target. A DKIM TXT query can help follow the public-key chain. These observations prove DNS publication, not live signing or alignment.
Next, review Sender Email Addresses in General Settings. Element451 requires these addresses to be all lowercase. Use the approved address on the authenticated domain, not an arbitrary first address in the list.
The Default column has a broader effect:
- For most sends, a default is optional. If none is set, Element451 falls back to the first sender address on an authenticated domain.
- Bolt Campaign Copilot requires a default sender email on an authenticated domain.
Choose or change the default only with approval for the affected campaigns. Do not turn a global preference into a silent side effect of authenticating one domain.
In the campaign's Advanced Email Settings, explicitly check Sender Email Address, Sender Name and Reply Address. Element451 supports version-specific email settings, so inspect each relevant version rather than assuming the default covers them all. See its email campaign configuration guide.
7. Verify a controlled native email, not just a preview
Use an approved, tiny audience of controlled staff/test addresses and harmless content. Do not use real student records, guardians' addresses or sensitive application information merely to test authentication.
Element451's testing guide distinguishes:
- Preview: a visual view in the builder, not delivered-mail evidence.
- Test to one email address: a real message, but without tokens or attachments, even if that address belongs to a test record.
- Test to a segment: supports versions, tokens and attachments.
With an approved campaign open, the blue Test button leads to channel and recipient choices. Select Email only for this task, choose the intended controlled address or test segment, recheck the actual audience, then use the final Test control only when the send is authorized. Do not test SMS or push merely because the campaign also contains them.
Where personalized sender settings or the final campaign route need validation, use a separate controlled native campaign rather than relying solely on a preview or a single-address content test. The campaign creation procedure provides Engagement → Campaigns → One-Time Communications → + New Communication, with an email channel and a selected audience segment. Keep the campaign as a draft until its sender, segment and release approval are checked. Ongoing communications are workflow-triggered and need their own controlled test plan; do not trigger a real application or payment workflow for this purpose.
Check hidden recipient paths too
Review Send To, CC, BCC and all tokens before any test or live send. Element451 documents fallback from a missing school/secondary email to the primary address, and from a missing primary address to CC. Tokens can also select guardian, counselor or relationship addresses. Use synthetic test records with known destinations; remove unintended recipients rather than assuming the selected segment alone bounds the send.
Public preview links can be opened without logging in. Do not share a preview containing private student data as an authentication diagnostic. A screenshot or preview URL still cannot establish SPF or DKIM success.
Require trusted, aligned results
Inspect the received message through the actual receiving service's message details or original-message view. Establish which authentication results were generated inside its known processing boundary, including its documented handling of externally supplied Authentication-Results fields. A familiar authserv-id or header position alone is not a trust guarantee. Ignore attacker-inserted fields; if the boundary cannot be established, obtain the receiver administrator's interpretation. See RFC 8601.
Record the intended unchanged From domain, the actual MAIL FROM/Return-Path, the relevant SPF result, and the intended Element451/SendGrid DKIM signature's d= and s= values. Acceptance requires:
- The intended native signature passes cryptographic verification.
- Its signing domain aligns with the intended visible From under the applicable DMARC policy.
- The trusted receiver reports
dmarc=pass. - No unexpected sender rewrite or fallback substitutes a different identity.
Under relaxed alignment, qualifying identifiers share the same Organizational Domain; strict alignment requires equality. A branded child envelope domain does not automatically satisfy strict SPF alignment. Preserve the approved mode and resolve mismatches, rather than relaxing policy to make a test pass.
DMARC passing through SPF does not prove the intended DKIM works. A passing unrelated signature is also insufficient. See EmailAuth's raw DKIM results versus aligned DKIM policy results and the signature rules in RFC 6376.
Investigate SPF fail, temperror and permerror separately, even if aligned DKIM permits DMARC to pass. They represent different problems: authorization failure, temporary evaluation failure, and invalid-policy or evaluation-limit failure. Authentication is not an inbox-placement guarantee.
8. Troubleshooting and safe recovery
| Symptom | Likely distinction to investigate | Safe action |
|---|---|---|
| Authentication setting is unavailable | Required Administrator permission or account applicability | Ask the account owner to resolve access; do not create a standalone SendGrid account |
| Data is populated but Status is not green | Instructions exist, but configuration is not accepted | Compare exact authority, owners, targets, conflicts and DMARC location |
| Root DMARC works at receivers but Element451 check fails | Product checks the exact card domain | Have the security owner approve an exact-domain policy preserving effective inherited protection |
| DNS editor shows duplicated domain suffix | Full name entered into a relative-name field | Correct the owner convention and recheck the saved full name |
| CNAME resolves as a proxied address or flattened result | Alias visibility differs from required publication | Apply the supported per-record/zone configuration without disrupting unrelated records |
| Bolt cannot create the campaign | No authenticated default sender | Obtain approval for an appropriate default; do not silently change a shared one |
| Green status but unintended From or signature | Sender fallback, version settings or backend identity | Hold release and inspect the actual native route and selected sender |
| Test lacks tokens or attachments | Single-address test mode limitation | Use an approved synthetic test segment when those features matter |
| DKIM passes but DMARC fails | Signature may not align with intended From | Compare actual domains under the existing policy; do not weaken alignment |
If a planned campaign might use a broken identity, pause its release. For a scheduled one-time communication, Element451 documents Stop in the send-settings sidebar; the resulting Stopped campaign remains editable. That is not a recall of mail already sent. Do not resend merely because a status seems slow: establish what actually happened first to avoid duplicate messages.
Restore only an approved prior record or sender setting after checking shared dependencies. Preserve root and child DMARC protection, legitimate SPF senders, active selectors and existing delegations. Do not delete and recreate the authentication domain, switch defaults or disable security as a routine diagnostic shortcut.
Maintain an operational record of the domain card, issued packet, approved policy, exact DNS owner mapping, green status, intended sender/default/version choices and controlled-message results. Recheck after DNS migrations, provider key changes or sender-policy changes. No passwords or private keys belong in that record.
Sources and verification boundary
Those displayed dates are separate from this guide's check date. The inspected authentication overview shows only a relative updated age, so no absolute date is assigned to it.
This is a configuration and acceptance guide, not a report of customer implementation. No account was accessed, DNS published, instruction email sent, sender/default changed or campaign delivered for this article. Actual platform acceptance, message results and owner approval remain implementation steps.