Contact Form 7 Developer Melbourne: Enquiries That Actually Arrive

That message means CF7 handed the mail off without an immediate error: it is not a delivery confirmation, and the distinction is the whole problem. What happens after the handoff is invisible to the plugin. In most cases this is the site sending unauthenticated mail from an address the domain does not vouch for, and the receiving server is discarding it silently. It is fixable in well under an hour and it stays fixed.

Almost certainly not, and it is better to hear that plainly. CF7 stored nothing and the mail was never delivered, so there is nothing to restore from: this is the cost of the default configuration rather than anything you did wrong. Occasionally a server-level mail log still holds a few days of history and it is worth one look. Then we make sure the next one is never lost.

Not for this. Every form plugin on WordPress hands mail to the same underlying function, so a site with unauthenticated sending will lose enquiries from any of them: you would be paying to move a problem. Fix delivery and add logging, then decide about plugins later on features, calmly, rather than in the middle of a crisis.

No. It is actively maintained and has a long, unremarkable security record, which is more than can be said for many plugins that come bundled with themes. What it is, is minimal: it does exactly what it says and nothing else, and most of the trouble people attribute to it comes from the things it deliberately does not do. Those gaps are worth filling, and none of them is a reason to distrust the plugin.

Stop them before they reach WordPress rather than filtering them afterwards, because a submission CF7 evaluates has already cost you server work and a filtered one leaves no evidence you can review. A challenge at the edge removes the bulk of it. Get the submission log running first, though, if an over-eager filter does catch a real customer, that log is the only way you would ever find out.

Yes, through the plugin's second mail template, and it is worth setting up because it reassures the sender that the form worked. Two cautions: it must send from an authenticated address or it will be junked exactly like the notification, and it should not echo back everything they typed if the form collects anything sensitive.

Usually the theme, not CF7: the plugin outputs plain markup and inherits whatever the theme says about inputs, and builder modules frequently style the fields while forgetting the error and success messages. The practical consequence is that a visitor whose submission fails validation sees nothing explaining why, so they give up and you never hear about it. We check the form in its failure state, which is the state nobody tests.

Yes, and the parts that need thought are what the size limit should be, what file types you will accept, and where the uploads end up. CF7 attaches the file to the notification email, which means a large attachment can push the message over the receiving server's limit and the whole enquiry disappears with it. On forms that genuinely need big files, the better pattern is storing the upload and sending a link.

If someone on your team is comfortable with DNS and an SMTP plugin, the delivery fix is within reach and the steps above are the whole of it. Where people come unstuck is the domain records: an SPF or DMARC record set wrongly can stop your ordinary business email arriving as well as the form's. That is the part worth handing to someone who does it routinely.

Send a real test through the public form periodically and confirm it arrives from outside your own network: sending to yourself from the same server proves less than people think. This is one of the checks included in a care plan from $159/mo, because a form that quietly stops delivering is one of the few site faults that costs money continuously while showing no symptom at all.