Credentials Vault & DNS Compliance
Connect your email channels securely. Credentials are encrypted in our vault with AES-256, and domain settings are monitored for SPF, DKIM, and DMARC compliance.
Two responsibilities sit in this module, and they share a theme: verifying that something is genuinely yours before mail depends on it. The vault protects the credentials that let the platform send as you. The DNS checker confirms that receiving providers will accept those messages as legitimately yours.
How credentials are actually handled
SMTP credentials are the most sensitive data the platform holds, because they are live sending capability rather than a record of past activity. They are encrypted at rest with AES-256 in storage kept separate from your account record, decrypted only in memory at the moment a message is relayed, and never written to logs. After saving, they are never displayed back in full - which occasionally frustrates people re-checking their own setup, and is the correct trade. Removing a sending account deletes them permanently.
Verifying the connection before you rely on it
A credential that is merely stored is not a credential that works. Adding a sending account performs a real SMTP handshake against the host, so a wrong password, a blocked port, or a provider requiring an app-specific password surfaces during setup rather than partway through a campaign. STARTTLS on port 587 is enforced on every connection, so credentials are never transmitted in clear text even on a network you do not control.
What the SPF, DKIM and DMARC scanner checks
Adding a domain triggers live DNS TXT lookups against the records that mailbox providers will themselves query. The scanner reports which of the three are present, valid, or misconfigured. This matters because authentication failures are silent from the sender's side: your campaign reports as sent, the messages are simply filtered on arrival, and nothing tells you why. Checking before the first send converts an invisible problem into a visible one.
Why alignment is the failure people miss
A domain can publish a correct SPF record and still fail DMARC. If the envelope sender belongs to a sending platform rather than to you, SPF validates that platform's domain, not the one your recipient sees in the From header. Those two must match for DMARC to pass. This is precisely why any competent sending tool asks you to add DNS records for your own domain rather than letting you send immediately on theirs.
Feature Breakdown
Encrypted Credential Vault
Protects your SMTP credentials using industry-standard AES-256 encryption. Plaintext passwords never touch logs or persistent databases.
Technical Capabilities:
SMTP Handshake & OTP Verification Flow
Ensures newly connected credentials are valid and active before making them eligible to send campaign emails.
Technical Capabilities:
SPF / DKIM / DMARC Domain Checker
Guards your sender reputation by scanning DNS settings to ensure compliance with Yahoo, Gmail, and Outlook policies.
Technical Capabilities:
Plan Quota Limit Enforcement
Monitors and limits domain and email additions according to subscription package tiers.
Technical Capabilities:
Spec Sheet
Need a Deep Dive?
See exactly how this module manages background queues, encryption, and delivery logic in our sequence flowchart.
View technical guideReady to Connect Your Nodes?
Scale your deliverability with our intelligent sharding relay. Add your domains and start landing in the inbox.
Credentials Vault & DNS Compliance questions.
The specifics people ask about before relying on this part of the platform.
How are my SMTP credentials protected?
Credentials are encrypted at rest with AES-256 in a vault kept separate from your account record, decrypted only in memory at the moment a message is relayed, and never written to logs or shown back to you in full after saving.
Does the platform check my SPF, DKIM and DMARC setup?
Yes. Adding a domain triggers live DNS TXT lookups that report which records are present, valid or misconfigured, so you can fix authentication before it costs you a campaign rather than after.
How do you confirm a sending account actually works?
A real SMTP handshake is performed against the host before the account is accepted, so a wrong password or a blocked port surfaces at setup time instead of mid-campaign.
What happens if I hit my plan's domain or mailbox limit?
Quotas are enforced at the API level. You are prompted to upgrade rather than silently charged for the overage or allowed to exceed the limit.