Q4’s documented default website-alert route uses no-reply@q4inc.com as its sender, with DKIM handled through Q4’s SendGrid delivery service. A company reply address is a separate setting. Do not add a guessed Q4 or SendGrid SPF include to your corporate DNS just because your investor-relations website sends alerts. Q4 email security.
This guide covers the default website-subscriber alert route described in Q4’s activation resources. It does not establish a custom-domain From configuration, every Q4 product’s behavior, or a separately contracted sending route. No live customer account or message was tested.
Which identity does each setting control?
Q4 documents default From and ReversePath addresses under its own domain and lets clients nominate a company mailbox for replies. It also requests a support contact or page and a privacy-policy link for the subscriber experience. Q4 email alert information.
The distinctions matter:
- From is the visible sender address. DMARC evaluates its domain.
- Reply-To directs replies. It does not turn the original message into authenticated mail from your company domain.
- SMTP MAIL FROM is the envelope identity SPF evaluates. Inspect actual receiver results, rather than treating a documentation label or reply address as proof of the transmitted envelope.
- DKIM
d=identifies the signing domain. A signature must pass and align with visible From to contribute to DMARC. - A support link or address in the body is content, not an SPF or DKIM identity.
Under relaxed alignment, related domains within the same Organizational Domain can align; strict alignment requires an exact domain match. Your corporate reply domain does not align a vendor-domain From simply by appearing in Reply-To. See SPF identities and DMARC alignment.
Give Q4 an approved alert-configuration brief
Prepare these decisions for your Q4 implementation contact or the team responsible for the existing alert setup:
- Identify the website and the exact alert types being configured. Q4’s examples include releases, events, reports, filings and stock-quote alerts; only authorize the types your organization actually wants.
- Confirm whether the default vendor-domain sending route is the intended arrangement. If your organization requires its own domain in visible From, request supported custom-domain documentation before treating the default as an equivalent solution.
- Specify an active, monitored company reply mailbox if replies should reach your team, and identify who owns that inbox.
- Approve the support destination and privacy-policy link shown to subscribers.
- Agree a safe verification path before enabling production distribution.
The source describes coordination with Q4, not a self-service DNS wizard. It also describes optional subscriber-list imports; uploading a list or enabling distribution is a separate authorized action, not a prerequisite for examining authentication. Provider setup information.
Retain the previously approved values and owners so that a mistaken reply-routing change can be reversed precisely.
What not to change in DNS
The documented default identities belong to Q4, so this workflow supplies no corporate-domain DKIM key or SPF include to paste into your DNS. Creating a TXT policy on your corporate domain cannot repair a failure for an unrelated vendor envelope domain.
Do not duplicate or replace your existing SPF policy, weaken your DMARC policy, or change MX routing, nameservers or security controls to accommodate this default route. Your corporate mailbox service needs its own authentication for mail that it sends, including your team’s replies, but that is a different sending path.
Q4 says its default delivery service automatically uses DKIM and no longer requires IP whitelisting for employees to receive alerts. Treat that as provider documentation, not proof that a particular delivered message passed. Do not disable filtering or trust a sender solely by display name. Q4’s security explanation.
For a proposed branded From route, obtain current provider-specific evidence covering supported product, domain verification, account-issued DNS records, signing activation, actual envelope identity and acceptance testing. The default-route documentation does not establish those steps. Do not substitute generic SendGrid-account instructions for a Q4-managed service.
Verify a real alert safely
Coordinate a controlled test with Q4 using approved recipients and non-sensitive content, or inspect the next already-authorized alert. Do not publish a dummy press release, filing, financial report or market announcement merely to trigger an email. Do not import a subscriber list or send to investors just for testing.
At the receiving mailbox, inspect the original message rather than a forwarded copy:
- Confirm that the observed From is consistent with the approved route. If it is a corporate domain instead, the default-route scope no longer answers the whole configuration question.
- Inspect Reply-To and confirm that a controlled reply would reach the approved monitored mailbox before sending it.
- Record the actual SMTP envelope identity and SPF result.
- Record the intended DKIM signature’s domain and result. Require that signature to pass and align with the actual visible From, plus a trusted receiver
dmarc=pass, before claiming that DKIM authenticates this route. A DMARC pass via SPF alone does not demonstrate working DKIM. - Investigate SPF failure, temporary DNS errors and permanent policy errors separately, even where DKIM enables DMARC to pass.
Use authentication results attributable to the known receiving system’s processing boundary and its documented treatment of externally supplied Authentication-Results. Matching server-name text or a header’s position is not enough. Ask the receiver’s mail administrator to identify trustworthy results when necessary. Authentication-Results trust boundary.
A passing vendor-domain result authenticates the vendor-domain route, not your company merely because the message contains your branding. See raw DKIM results versus aligned policy results, reviewed against its retained body rather than freshly tested on the live site. Successful authentication also does not guarantee inbox placement.
Troubleshooting and rollback
Replies go to the wrong place: inspect the original Reply-To and compare it with the approved setup brief. Ask the setup owner to restore the previous reply destination if necessary. Do not edit corporate SPF to fix a reply-routing mistake.
An alert is missing: confirm the relevant alert type and authorized subscription with Q4, then have the recipient check junk or quarantine through normal administrative processes. Delivery failure is not automatically an authentication failure.
DKIM or DMARC fails: preserve a redacted original-header sample, timestamp, intended route and receiver results. Ask Q4 to investigate its managed sending path. Do not publish keys discovered in another customer’s message or grant blanket filtering exceptions.
A custom sender is requested: keep it out of rollout until Q4 provides the specific supported workflow and a controlled message demonstrates intended aligned authentication. Restore a previously working approved route only in coordination with its owner.
When escalating, share only the evidence needed through an approved support channel. Exclude passwords, private keys, subscriber lists and unpublished financial information. No DNS rollback should be necessary for the default-route coordination described here because no corporate DNS change is prescribed.